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20.  AbSTRACT  (Cont* d) 

N61339-73-C-0097. 

Phases  I,  II  and  III  were  accomplished  by  the  IBM  Federal  Systems  Division 
with  the  Training  Analysis  and  Evaluation  Group,  Orlando,  Florida,  providing 
technical  guidance  and  support.  The  overall  DOTS'  objective  is  to  provide 
Naval  Education  and  Training  Command  (NAVEDTRACOM)  management  with  additional 
tools  in  the  form  of  computerized  mathematical  models  to  assist  in  predicting 
the  quantitative  impact  of  training  resource  decisions.  The  planning  process 
will  be  enhanced  by  providing  decision  makers  with  the  capability  to  econom- 
ically and  rapidly  consider  a wider  range  of  alternatives. 

Phase  I was  a study  and  definition  effort  resulting  in  a complete  functional 
description  of  the  NAVEDTRACOM;  a strategic  definition  of  the  social,  politi- 
cal, economic  and  technological  environments  pertinent  to  the  naval  education 
and  training  system  in  the  1980's;  a list  of  existing  and  potential  models 
amenable  to  computerization  and  to  improving  the  decision-making  process. 

Phase  II  was  devoted  to  the  selection  and  development  of  three  mathematical 
models  from  the  Phase  I list  of  candidates.  The  three  were  the  System  Capa- 
bilities/Requirements and  Resources  (SCRR),  the  Educational  Technology  Evalua- 
tion (ETE),  and  the  Training  Process  Flow  (TPF)  models. 

Phase  III  centered  on  evaluating  the  selected  models  at  the  Fleet  Train- 
ing Center,  Norfolk,  VA.  An  important  recommendation  from  the  Test  and 
Evaluation  conducted  during  Phase  III  was  that  DOTS  should  investigate 
model  applications  at  higher  command  levels.  TRAM  responds  to  this  recom- 
mendation. 
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The  Phase  IV  TRAM  development  began  with  a functional  analysis  performed  in 
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viewed with  personnel  at  CNTECHTRA,  Memphis,  Tennessee.  Model  design  and 
development  proceeded  from  these  preliminary  specifications.  A field  test 
at  CNTECHTRA  was  scheduled  in  October  1976,  with  this  Phase  IV  Final  Report 
containing  the  results. 

The  Phase  IV  DOTS  Utility  Assessment  at  TRAPAC  yielded  significant  cost 
and  resource  data  which  will  be  useful  in  planning  follow-on  application 
and  model  development  efforts.  These  results  are  also  incorporated  into 
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FOREWORD 

The  Design  of  Training  Systems  (DOTS)  project  objectives  are  in  consonance  with 
the  requirements  of  Advanced  Development  Objective  ZPN07  (formerly  ADO  4303X), 

Education  and  Training  Development.  ZPN07  includes  a number  of  projects 
concerned  with  demonstrating  and  evaluating  the  technical,  operational  and 
financial  feasibility  of  applying  advanced  technological  applications  to 
improving  the  training  process. 

The  Bureau  of  Naval  Personnel  initiated  the  original  ADO  in  1966  to  make  naval 
training  more  responsive  to  the  changing  times.  As  one  project  under  this 
effort,  DOTS  was  designed  to  improve  the  process  of  managing  training  resources 
through  application  of  the  techniques  of  system  analysis  and  system  simulation 
as  accomplished  through  mathematical  modeling.  The  end  objective  is  a family 
of  computerized  mathematical  models  enabling  training  management  to  more 
rapidly  predict  the  impact  of  changes  in  training  resource  availability  or  re- 
quirements. 

The  majority  of  education  and  training  was  reorganized  in  1971  under  one  command. 

Chief  of  Naval  Education  and  Training  (CNET).  Because  of  this  change,  DOTS 
responsibility  was  transferred  to  CNET  in  March  of  1972;  more  specifically, 
to  the  Training  Analysis  and  Evaluation  Group  (TAEG),  Orlando,  Florida.  The  new 
CNET  organization  greatly  increased  the  potential  benefits  tc  be  gained  from  the 
increased  application  of  new  management  techniques  and,  therefore,  from  the 
DOTS'  R&D  effort.  DOTS  began  in  February  of  1973,  with  the  majority  of  tasking 
being  contracted  to  the  International  Business  Machines  Corporation,  Federal 
Systems  Division,  Cape  Kennedy  Facility,  located  at  Cape  Canaveral,  Florida. 

Chief  of  Naval  Technical  Training  (CNTECHTRA)  personnel  providing  substantial 
input  to  TRAM  design  were:  CDR  Ian  Watson,  CDR  Jack  Davis,  Mrs.  Jerry  Trobaugh, 
and  Messrs.  John  Andrews,  Bill  Cox,  Jerry  Glad,  floreland  Ray,  Mel  Robey,  Dave 
Thomas,  Wilson  Thomas  and  Richard  Trannis.  Their  participation  in  this  effort 
is  greatly  appreciated. 

Mr.  Ray  Bryant  and  LCDR  Tom  Ferrier  contributed  significantly  to  the  finalization 
of  DOTS  model  enhancements  and  to  the  installation  of  the  major  data  base 
maintenance  system  at  COMTRAPAC.  John  Finnegan  at  TRAPAC  provided  exceptional 
cooperation  to  both  of  the  above  tasks. 

■I 

The  Training  Analysis  and  Evaluation  Group,  Dr.  A.  F.  Smode,  Director;  project  1 

team  members  Messrs.  M.  Middleton  and  W.  Lindahl,  complemented  the  contracted  j 

effort  by  providing  direction  and  guidance,  establishing  organizational  interfaces,  ! 

and  assisting  in  the  performance  of  the  utility  assessment.  | 
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SECTION  I 
INTRODUCTION 

BACKGROUND 

The  Training  Requirements  Analysis  Model  (TRAM),  developed  in  Phase  IV,  is  the 
result  of  recommendations  from  the  Phase  III  Test  and  Evaluation  (T&E)  of  the 
training  center  models.^  These  earlier  developed  models  were  employed  in  a 
rather  well-defined  sector  of  the  training  system.  Their  application  within 
the  training  system  was  analyzed  in  a prior  report. ^ The  final  study  results 
of  those  models  are  described  in  Section  V of  this  repc-"t. 

The  analysis  and  design  of  the  training  center  level  models  established  a knowl- 
edge and  technology  base,  part  of  which  was  incorporated  into  TRAM.  This  transfer 
of  an  application  and  technology  framework  assisted  the  integration  of  TRAM 
objectives  with  the  overall  project  goal,  namely  to  provide  training  management 
with  the  visibility  and  control  necessary  for  the  effective  planning  of  resources 
required  to  meet  a wide  range  of  training  demands.  It  was,  however,  recognized 
that  this  goal  could  be  met  best  with  models  targeted  at  the  Functional  Command 
and  Chief  of  Naval  Education  and  Training  (CNET)  level. 

The  T'  ctional  analysis  proceeded  from  the  in-depth  review  of  the  prior 

mod  ire  specific  information-gathering  task  at  these  higher  command 

le  eral  meetings  were  held  between  the  project  analysts  and  key  train- 

in  lals  responsible  for  program  and  resource  planning  at  CNET,  Chief  of  Naval 

Technical  Training  (CNTECHTRA),  Commander  Training  Command,  U.S.  Atlantic  Fleet 
(COMTRALANT) , and  Commander  Training  Command,  U.S.  Pacific  Fleet  (COMTRAPAC). 

The  meetings,  part  of  the  early  Phase  IV  effort,  identified  the  requirements 
of  the  Functional  Commands  so  that  the  TRAM  specification  effectively  melded 
the  prior  modeling  technology  base  with  the  stated  needs  of  the  training 
managers. 

TRAM  OBJECTIVES 

The  objectives  of  the  TRAM  portion  of  Phase  IV  of  the  DOTS  project  were  as 
follows: 

1.  To  merge  the  technologies  developed  for  the  Training  Process 
Flow  (TPF)  model  and  the  System  Capabilities/Requirements  and 
Resources  (SCRR)  model  into  a new  model  for  student  and  re- 
source planning  and  management.  This  new  model  should  test 
the  feasibility  of  meeting  planned  training  loads  with  available 

^DiGialleonardo,  Frank,  1976.  Design  of  Training  Systems  (DOTS)  Project: 

Test  and  Evaluation  of  Phase  II  Models.  Special  Report  76-10,  Navy  Personnel 
Research  and  Development  Center,  San  Diego,  CA. 


2 

Duffy,  Larry  R. , 1976.  DOTS  Utility  Assessment:  The  Training  Process  Flow 
and  System  Capabilities/Requirements  and  ResouTces  Models  Operating  in  the 
TRAPAC  E^ironment.  TAEG  Report  No.  33,  Training  Analysis  and  Evaluation 
Group,  Orlando,  f^L. 
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resources,  calculate  resources  required  to  meet  new  requirements, 
and  indicate  resource  surpluses  on  a training  center  (UIC)  basis. 

2.  To  identify  data  required  and  to  establish  and  validate  a 
baseline  data  base  for  use  in  model  testing  and  validation. 

3.  To  study  the  entire  Program  Budget  Decision  (PBD)  process 

at  the  CNET  and  Functional  Command  level,  including  CNET's  role  in 
the  overall  Planning,  Programming  and  Budgeting  System  to  assure 
the  TRAM  model  fills  a useful  role  in  providing  managerial  support. 

The  resultant  of  this  phase  of  the  project  is  to  be  a computer-based  model/ 
data  base  system  usable  at  the  CNET/Functional  Command  level  which  will 
augment  the  existing  decision  process  relative  to  increments,  decrements, 
feasibility  studies.  Program  Budget  Decision,  etc. 

TRAM  DEVELOPMENT  TASKS 

The  TRAM  portion  of  Phase  IV  was  broken  into  two  major  tasks. 

TASK  1 - DEFINE  TRAM  FUNCTIONAL  SPECIFICATION.  The  design  of  a new  model 
such  as  TRAM  must  start  with  the  formulation  of  functional  specifications, 
i.e.,  analysis  of  the  purpose  of  the  model  and  determination  of  the  model 
application,  data  sources,  and  outputs.  This  task  was  divided  into  two 
parts.  The  initial  part  consisted  of  interviewing  key  personnel  at  CNET, 
CNTECHTRA,  COMTRALANT,  and  COMTRAPAC.  This  was  done  concurrently  with  the 
analysis  of  documentation  on  existing  Navy  systems,  such  as  Resource  Management 
System  (RMS),  Navy  Integrated  Training  Administration  System  (NITRAS), 

Recruit  Allocation  Control  System  (RACS),  etc.,  and  an  analysis  of  all 
available  literature  concerning  the  entire  Planning,  Programming  and  Budgeting 
System  as  it  relates  to  CNET. 

The  final  step  was  to  correlate  the  DOTS  capabilities  with  the  identified 
CNET/Functional  Command  requirements.  The  resultant  of  this  task  was  the 
TRAM  Functional  Specification  delivered  in  December  1975,  and  superseded  by 
the  TRAM  Functional  Description  published  in  April  1976. 

TASK  2 - DEVELOP  TRAM.  The  second  major  task  during  the  TRAM  portion  of 
Phase  IV  was  the  development  of  the  TRAM  model.  The  Functional  Specification 
developed  in  TASK  1 was  used  as  the  basis  for  design.  The  model  was  constructed 
using  a building-block  technique,  using  the  results  of  parametric  studies  and 
other  analyses  of  the  bulk  data.  This  development  is  covered  in  Section  III 
of  this  document.  The  final  part  of  TASK  2 was  a user  evaluation  or  field 
test,  conducted  at  CNTECHTRA.  The  results  of  this  field  test  are  contained 
in  Section  IV  of  this  report. 

SCRR  AND  TPF  UTILITY  ASSESSMENT  AT  TRAPAC  TASKS 

The  SCRR  and  TPF  Utility  Assessment  portion  of  Phase  IV  was  divided  into  four 
major  tasks. 
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TASK  1 - TRAPAC  FIELD  TEST.  This  task  consisted  of  the  installation  of  SCRR 
and  TPF  software  at  the  Training  Command  Pacific  (TRAPAC),  identification  of 
model/data  base  applications,  utilization  of  the  models  to  solve  identified 
problems,  definition  of  enhancements,  and  an  evaluation  by  a Navy  review  team 
of  the  field  test  results.  These  results  were  documented  in  the  DOTS  UTILITY 
ASSESSMENT,  TAEG  Report  No.  33. 

TASK  2 - MODIFY  SOFTWARE  TO  INCORPORATE  ENHANCEMENTS.  Three  major  enhancements 
identified  during  the  TASK  1 field  test  were  incorporated  into  the  DOTS  models/ 
data  base  software.  These  included  an  instructor  billet  computation  program, 
several  data  base  format  changes,  and  a new  data  base  maintenance  system.  The 
major  changes  from  this  task  were  documented  in  the  DOTS  TRAPAC  USER'S  MANUAL, 
TAEG  Report  No.  36. 

TASK  3 - TRAIN  TRAPAC  PERSONNEL,  INSTALL  SYSTEM.  TRAPAC  personnel  were  trained 
in  the  operation  of  the  DOTS  models/data  base  over  a five-week  period.  During 
that  same  period,  the  new  software  was  installed  and  personnel  were  trained  in 
the  use  of  the  data  base  maintenance  system.  Maintenance  and  operational  costs 
were  recorded  and  have  been  incorporated  into  Section  V of  this  report. 

TASK  4 - SYSTEM  DOCUMENTATION.  The  system  documentation  consisted  of  a combined 
user's  guide  and  programmer's  manual  for  the  DOTS  data  base,  SCRR,  and  TPF  models 
(TAEG  Report  No.  36). 

The  primary  focus  of  this  report  is  to  present  the  analysis,  design,  development, 
and  test  results  that  relate  to  TRAM.  Sections  II,  III  and  IV  of  this  report 
address  these  topics. 
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SECTION  II 

TRAM  FUNCTIONAL  ANALYSIS 


TECHNICAL  APPROACH 

No  analysis  of  a complex  organization  can  be  made  without  thoroughly  understanding 
the  business  of  that  organization  and  how  infortiiation  sv-tems  support  it. 

CNET,  with  the  consolidation  of  all  training  under  a single  command,  has  a 
function  larger  and  more  complex  than  ever  before.  The  command  must  cope  with 
the  large  and  varying  numbers  of  trainees,  controlling  a far-flung  organization, 
and  adjusting  with  the  technical  advances  that  alter  the  training  requirements 
as  well  as  introducing  challenges  in  the  form  of  new  training  methods.  The 
overriding  goal  of  CNET  can  be  stated  quite  simply:  "To  provide  the  fleet  with 
a proficient  occupant  for  every  billet  by  means  of  the  most  efficient  utilization 
of  available  resources. "3  In  other  words,  the  training  command  must  make 
available  to  the  fleet  qualified  individuals  in  the  right  place  tt  the  right 
time  and  in  the  right  numbers. 

Numerous  analytic  methods  could  have  been  applied  to  the  study  of  th:  CNET 
organization.  For  this  task,  the  job  was  broken  into  three  steps.  First,  it 
was  necessary  to  identify  the  preliminary  activities  required  for  a detailed 
study  of  CNET  and  the  functional  commands.  Second,  the  activities  necessary  to 
understand  the  business  of  CNET,  including  how  current  information  systems 
support  it  and  what  situations  might  be  amenable  to  solution  using  mathematical 
models,  were  outlined.  Third,  the  scope  of  the  TRAM  development  effort  had  to 
be  assessed  in  light  of  the  identified  requirements,  considering  existing 
resource  capabilities  and  the  extent  to  which  prior  modeling  technology  could 
be  applied.  These  three  steps  led  to  the  TRAM  functional  specification. 

Figure  II-l  outlines  this  tasking  structure  in  summary  form. 

DISCUSSION  OF  INDIVIDUAL  TASKS 

The  identification  step  included  the  preparatory  activities  necessa>"y  to  insure 
continuity  and  success  in  the  accomplishment  of  the  project  objectives  within  a 
reasonable  time  period.  By  going  through  an  identification  step  valuable  time 
was  saved  by  team  members  and  travel  was  held  to  a minimum. 

An  initial  activity  was  to  develop  a study  action  plan  - that  is,  who  would  be 
responsible  to  do  what.  This  involved  setting  p.oiect  objectives,  and  then 
scheduling  a course  of  action  for  Step  2. 

In  Step  2 the  first  objective  was  to  define  NAVEDTRACOM  requirements  in  the 
planning  area.  The  DOTS  Phase  I analysis,  completed  in  December  1973  when  CNET 
was  a newly  created  command,  was  reviewed  and  updated.  This  analysis  identified 
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demands  placed  on  CNET  by  other  commands,  and  demands  placed  by  CNET  on  its 
functional  commands. 

The  second  objective  was  to  determine  the  status  of  current  solutions  to  planning 
problems.  CNET  appears  successful  in  conducting  its  business;  therefore  this 
objective  was  to  provide  an  understanding  of  how  their  business  process  operates, 
and  how  current  and  planned  information  systems  support  it. 

The  third  objective  was  to  establish  the  status  of  current  and  planned  automated 
data  processing  systems.  This  information  was  to  provide  an  understanding  of  the 
current  support  given,  point  out  the  direction  in  which  this  support  is  going,  and 
to  allow  development  of  a system  with  minimum  data  requirements  while  avoiding 
overlapping  or  duplication  of  functions. 

The  objective  of  Step  3 was  to  correlate  the  existing  DOTS  capabilities  with 
identified  requirements.  The  overriding  objective  of  the  DOTS  project  is  the 
application  of  mathematical  modeling  to  the  solution  of  problems  within  the 
training  command.  To  provide  maximum  utility  with  minimum  expense,  it  is  obvious 
that  any  new  model  should  draw  heavily  on  the  expertise  and  knowledge  gained  in 
previous  efforts.  It  was  then  decided  that  the  functional  specification  to  be 
developed  should  not  delve  into  entirely  new  technologies  or  into  different  areas 
than  those  already  explored. 

Based  on  these  objectives,  the  team  was  assigned  tasks,  a schedule  and  management 
support  plan  were  developed,  required  data  were  requested,  and  trips  to  CNET  and 
the  functional  commands  were  scheduled. 

CNET  ANALYSIS 

The  TRAM  study  initially  centeitd  on  CNET.  The  key  persons  Interviewed  were 
Mr.  B.  C.  Monnes  (CNET  N-301),  CART  W.  H.  Mayer  (CNET  N-6),  CAPT  J.  R.  White 
(CNET  N-31)  and  CDR  E.  S.  Baker  (CNET  N-73).  The  CNET  portion  of  this  analysis 
was  also  coordinated  with  Dr.  L.  R.  Mac  Keraghan  and  Mr.  E.  0.  Moore  of  TAEG, 
to  assure  the  analysis  did  not  duplicate  the  Navy  Training  Plan  Process  Study 
team  efforts  and  to  gain  the  benefit  of  their  knowledge  and  expertise. 

uiscu  sions  with  CNET  centered  around  a higher  level  of  planning  than  had  been 
encountered  on  earlier  visits.  In  its  simplest  form  the  basic  problem  facing 
the  planning  function  in  CNET  is  the  fact  that  training  requirements  are  not, 
for  the  most  part,  generated  from  within  the  NAVEDTRACOM,  but  rather  are  directed 
towards  CNET  by  other  commands.  Usually  the  resources  required  to  accommodate 
this  training  are  not  passed  along  with  the  requirement.  As  has  been  detailed 
in  the  Phase  I report,  the  Five-Year  Defense  Program  (FYDP)  is  the  normal  channel 
used  to  obtain  the  necessary  resources.  The  Program  Objective  Memorandum  (POM) 
is  the  vehicle  by  which  CNET  makes  known  to  the  CNO  its  unfunded  requirements. 

It  was  pointed  out  that  new  or  increased  trdining  requirements  do  not  automatically 
provide  the  resources  required  to  support  those  increased  requirements.  Obviously, 
as  CNET  maintains  no  pool  of  resources,  these  required  assets  can  only  be  obtained 
through  the  POM  or  through  internal  reprogramming  of  resources. 
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One  key  factor  became  evident  during  these  discussions  that  differed  from  previous 
ones.  In  the  past,  the  emphasis  was  always  placed  on  centralizing  the  planning 
process  at  CNET.  Now  the  emphasis  is  placed  on  the  Functional  Commander's  role 
in  this  process.  The  Functional  Commanders  are  now  being  directed  to  submit  to 
CNET  new  resource  requests  a minimum  of  ZH  years  in  advance  (5  years  for  MI ICON 
funds,  4 years  for  trainers)  of  the  time  they  are  required.  The  new  emphasis  is 
on  collecting,  correlating,  and  prioritizing  these  requirements,  with  the  actual 
computational  and  justification  effort  being  expended  by  the  Functional  Command. 

The  Mechanized  POM  being  prepared  for  CNET  is  the  vehicle  to  be  used  to  accommodate 
this  plan  of  action. 

Thus,  after  an  analysis  of  CNET's  role,  it  became  obvious  that  the  thrust  of  TRAM 
should  be  directed  toward  the  Functional  Command  level  where  the  detailed  analysis 
and  tradeoff  studies  are  conducted.  The  most  obvious  candidate  for  application 
of  the  TRAM  technology  was  CNTECHTRA.  This  command  not  only  operates  the  bulk  of 
CNET's  courses  but  also  conducts  planning  for  A and  C Schools  for  COMTRALANT  and 
COMTRAPAC.  Therefore,  the  remainder  of  the  TRAM  analysis  centered  primarily  on 
CNTECHTRA. 

CNTECHTRA  ANALYSIS 

The  plans,  programs  and  facilities  at  CNTECHTRA  are  the  responsibility  of  Code  N-2. 
Here,  planning  for  student  loads,  facilities,  major  increments  and  decrements, 
construction,  and  personnel  (staff  and  instructors)  is  carried  out.  The  analysis 
of  this  function  can  be  broken  into  two  major  divisions  - reprogramming  and 
increment/decrement.  Reprogramming,  in  its  simplest  form,  is  the  adaption  of 
training  resources  to  current  needs.  Examples  of  this  are  shifting  instructors 
from  one  course  to  another,  or  the  compromises  made  to  best  accommodate  Chief  of 
Naval  Operations  (CNO)  training  requirements.  The  increment/decrement  process 
is  less  operational  and  more  in  the  category  of  the  traditional  "what  if."  Long- 
range  plans  for  equipment,  personnel,  and  monies  are  the  resultant  of  this  process. 
The  major  difference  between  this  process  and  the  academic  posing  of  questions 
is  that  the  results  quite  frequently  become  fact;  therefore,  the  data  used  by 
the  planner  must  be  more  accurate. 

REPROGRAMMING.  One  of  the  most  frequent  day-to-day  activities  of  Code  N-2  is  the 
reprogramming  process.  Reprogramming  can  be  described  by  the  following  points; 

1.  Reprogramming  is  short-range,  and  usually  does  not  involve  immediate 
transfer  of  personnel  from  one  activity  to  another. 

2.  Reprogramming  does  not  contain  an  increment/decrement,  per  se.  Rather, 
the  movement  of  staff  to  new  jobs  is  involved,  and  not  the  longer  range 
movement  of  billets. 

3.  Head-count  at  an  activity  rarely  goes  up  or  down  immediately  as  a result 
of  reprogramming. 

4.  Reprogramming  is  a continuous  process.  Reprogramming,  therefore,  rep- 
resents the  refinement  of  previous  plans  (or  lack  thereof)  to  produce 
a workable  training  operation.  It  is  necessary  as  CNET  has  no  pool  of 
billets  or  bodies  to  shift  to  areas  where  workload  is  increasing. 
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5.  The  process  involves  setting  a priority  on  training,  and  then  accommo- 
dating as  much  of  the  desired  load  as  possible,  constrained  by  available 
resources.  The  term  "level"  was  often  applied  to  this  process.  This 
meant  that  resources  would  not  go  up  appreciably  to  accommodate  new 
load,  and  the  resources  had  to  be  shifted  from  lower  priority  training. 

The  following  observations  were  made  during  our  study  of  reprogranming: 

1.  NITRAS  was  the  source  of  data,  listing  what  a training  activity  had 
committed  to  do.  This  was  in  the  form  of  course  convenings,  lengths, 
schedules,  student/instructor  (S/I)  ratios,  capacities,  and  the  like. 

Also,  student  load  data,  once  approved,  are  placed  in  NITRAS  for  the 
current  and  out  years.  This  Data  Processing  (DP)  system  is  the  backbone 
of  the  NAVEDTRACOM  communication  concerning  student  load  and  course/class 
availability. 

2.  Instructor  billets  are  justified  based  on  courses  currently  in  NITRAS, 
and  are  subject  to  audit.  The  formula  for  justifying  these  billets  is 
based  on  student  load  and  course  requirements,  and  is  quite  consistently 
applied. 

3.  Billets  and  manpower  are  two  different  things.  The  billet  authorizes 

ctivity  personnel,  but  does  not  provide  them.  Actual  manning  may  be 
igher  or  lower,  but  almost  always  is  somewhat  lower  than  authorized. 

) the  reprogramming  process,  manning  is  somewhat  more  critical  than 
; is  in  the  increment/decrement  process. 

4.  Costing  during  the  reprogramming  process  is  not  usually  required.  Staff 
personnel  are  rarely  added  or  deleted  in  significant  numbers.  Reduction 
in  Force  (RIF's)  or  reassignment  costs  are  rarely  encountered.  Normally, 
the  reprogramming  process  consists  of  reassigning  current  resources 
within  approved  budgets. 

5.  The  reprogramming  process  is  not  oblivious  to  long-range  planning.  In 
fact,  it  is  hard  to  draw  a line  where  reprogramming  leaves  off  and  more 
academic  planning  begins. 

The  analysis  of  reprogramming  is  applicable  to  a TRAM  type  model.  The  data  sources 
for  this  planning  include: 

1.  Navy  Integrated  Training  Administration  System  (NITRAS) 

2.  Chief  of  Naval  Operations  (CNO)  Input  Requirements 

3.  Training  Requirements  and  Planning  Subsystem  (TRAPS)  Model 

4.  Manpower  Authorizations  (1000/2)  Billets 

5.  Civilian  Ceiling  Points 

6.  Manning  Levels 

Items  1,  2,  4 and  5 are  inputs  to  the  TRAM  model.  Item  3,  TRAPS,  is  currently 
undergoing  major  revision  and  the  study  of  this  system  was  dropped.  This  was 
due  to  the  fact  that  the  TRAPS  logic  depends  on  the  current  Navy  Enlisted 
Classification  (NEC)  system.  This  NEC  system  was  not  designed  to  aid  automated 
computer  planning  of  student  loads,  and  the  results  obtained  by  applying  computers 
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to  this  process  are  somewhat  inconsistent.  The  multiple  paths  to  a NEC  make  the 
computer  logic  difficult  and  inefficient.  Thus,  the  results  of  a manual  TRAPS 
analysis  are  used  as  an  input  to  the  TRAM  model.  The  remainder  of  the  data 
elements  consistent  with  reprogramming  will  be  discussed  in  the  model  design 
section  of  this  report. 

INCREMENTS/DECREMENTS.  The  other  major  process  studied  at  CNTECHTRA  was  the  in- 
crement/decrement process.  In  general,  this  can  be  broken  into  two  finer  sub- 
divisions, "what  if's,"  and  actual  increment/decrement  submissions.  The  "what  if's" 
as  described  are  those  short-fuse  questions,  the  answers  which  aid  a higher  echelon 
in  a decision  process,  but  the  results  of  which  must  be  refined  prior  to  imple- 
mentation should  that  occur.  Rules-of-thumb  and  averages  or  percentages  are  used 
rather  than  identifying  the  actual  billets  to  be  cut,  or  spelling  out  each  piece 
of  equipment  to  be  moved.  The  questions  asked  in  this  process  are  usually  not 
overly  complex  as  the  answers  would  be  too  time-consuming  and  expensive  to  produce. 
The  data  required  to  study  these  general  "what  if's"  are  as  follows: 

1.  NITRAS,  for  Training  Load  and  Courses 

2.  1000/2  Billets 

3.  Civilian  Ceiling  Points 

4.  Resource  Management  System  (RMS)  Cost  Data 

All  four  of  these  were  available  in  bulk  form  (data  processing)  and  were  made 
available  for  the  TRAM  Model.  The  logic  used  in  running  these  "what  if"  questions 
is  detailed  and  considered  within  the  scope  of  the  TRAM  capabilities. 

The  second  portion  of  this  increment/decrement  process  is  the  construction  of  a 
formal  study  or  report.  The  questions  posed  and  the  results  appear  similar,  but 
there  are  important  differences.  Rules-of-thumb  are  used  only  in  the  total  absence 
of  data  from  any  other  source.  A telephone  call  to  obtain  exact  information,  such 
as  shipping  charges,  replaces  averages.  A manual  analysis  of  the  1000/2  forms 
replaces  tying  personnel  to  percentages,  or  other  linear  techniques.  In  general, 
as  the  number  of  data  sources  increases  significantly,  the  detail  of  the  study  is 
magnified,  and  the  logic  involved  varies  with  each  study.  All  three  of  these 
factors  currently  make  a computer  replacement  of  this  process  infeasible.  It  was 
determined  that  at  best  TRAM  could  assist  in  portions  of  this  more  detailed 
increment/decrement  analysis. 

In  summary,  the  study  of  CNTECHTRA  resulted  in  the  following  conclusions  pertinent 
to  TRAM: 

1.  Student  loads,  as  obtained  from  CNO,  drive  CNTECHTRA;  presently,  CNTECHTRA 
has  insufficient  influence  in  this  planning  process. 

2.  Reprogramming  is  the  short-term  process  of  reassigning  current  resources; 
increment/decrement  refers  to  longer  range  acquisition  or  use  of  resources. 
However,  a major  part  of  this  latter  process  involves  considerable  re- 
programming to  be  effective. 
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3.  The  TRAM  model  should  be  able  to  assist  in  answering  "what  if s"  in  the 
area  of  short-term  planning  or  reprogramming.  The  data  sources  are 
available  in  bulk  form,  and  for  many  of  the  "what  if's"  the  logic  used 
in  the  decision  process  is  straightforward  and  amenable  to  automation. 

4.  "What  if's"  in  the  increment/decrement  process  are  applicable  to  TRAM 
processing,  as  long  as  the  result  is  used  to  study  the  implications 
of  a course  of  action  and  not  used  as  the  end  result  of  the  study. 

Total  automation  is  not  possible  as:  (a)  several  factors,  such  as 
equipment  costs  and  construction  costs,  must  be  figured  on  an  individual 
basis;  (b)  the  logic  used  in  determining  the  desirability  of  a course  of 
action  may  differ;  (c)  data  come  from  several  sources,  depending  on  the 
specifics  of  the  plan  under  study.  Based  on  this,  suggestions  such  as 
provisions  for  manual  entry  of  off-line  data  were  dropped  in  lieu  of  a more 
concentrated  effort  in  providing  a model  that  would  calculate  the  im- 
plication of  a course  of  action. 
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SECTION  III 

TRAM  MODEL  DEVELOPMENT 


INTRODUCTION 


The  TRAM  model  Is  r,  'el,  ■'nteractive,  user-oriented  system.  The  system 

consists  of  four  mt  'with  numerous  subprograms),  two  major  data 

bases,  and  cns  ret?  ise.  A front-end  program  interacts  with  the 

user  - providing  in'.  nd  prompting  - requesting  input  direction  in  a 

highly  simplified  fcriri^:  m ''  structuring  the  user  inputs  in  a form  to  cause 
the  model  program  to  respond  to  a relatively  complex  structured  "what  if"  type 
question.  The  types  of  user  questions  to  which  the  model  can  respond  deal  with 
incrementing,  decrementing,  and  consolidating  training  courses  and  training 
activities.  An  abbreviated  extract  of  the  Navy  Integrated  Training  Administra- 
tive System  (NITRAS)  Master  Course  Reference  File  (MCRF)  is  referred  to  by  the 
model  to  obtain  course  related  data.  An  instructor  computation  program  operates 
upon  the  NITRAS  course  level  data  to  determine  the  change  in  instructor  require- 
ments resulting  from  the  "what  if"  action.  Changes  in  instructors  as  well  as 
changes  in  Average-on-Board  (AOB)  are  passed  to  an  interface  program  which  calls 
upon  a cost  subroutine  to  compute  total  billet/ceiling  point  changes  for  each 
activity  affected,  to  calculate  the  Military  Pay,  Navy  (MPN)  and  Operations  and 
Maintenance,  Navy  (O&MN)  deltas,  and  to  print  a resource  change  summary  resulting 
from  the  “what  if”  action.  During  this  process,  reference  is  made  to  the  second 
major  data  base  containing  billet/ceiling  point  and  cost  data  by  activity. 

This  section  of  the  report  presents  the  detail  of  the  model  development  effort 
growing  out  of  the  functional  analysis  covered  in  Section  II.  It  outlines  the 
model  by  major  program,  describes  the  functional  specification  upon  which  model 
design  and  development  was  based,  and  discusses  Important  data  considerations 
in  the  creation  of  model  default  routines. 

TRAM  MODEL  DESCRIPTION 

Four  major  programs  comprise  TRAM.  They  are  shown  in  Figure  III-l  as  1)  PGM 
PARAM,  2)  PGM  TRAM,  3)  PROGRAM  ICALC  and  4)  PGM  IFACE  (or  IFACEI).  The  two  key 
data  bases  are  1)  NITRAS  MASTER  and  2)  NUIC,  XUIC  and  PCOST  MATRIX.  The 
reference  data  is  labeled  NITRAS  TABLES,  Following  are  descriptions  of  these 
major  model  components  as  well  as  of  the  other  programs,  executives,  data  bases, 
and  reports  shown  in  Figure  III-l. 

PGM  PARAM,  This  program  provides  the  major  interaction  between  the  system  user 
and  the  TRAM  model.  This  FORTRAN  language  program  requests  required  input  from 
the  user,  such  as  years  of  consideration,  default  characteristics,  etc.,  provides 
a menu  of  options  available,  and  in  a conversational  mode  allows  the  non-ADP 
oriented  user  to  set  up  a complex  model  run.  Keywords  such  as  QUIT,  HELP,  ?, 
DONE,  and  FIN  are  recognized  at  all  times  throughout  this  operation  to  guide  the 
model  user  with  minimal  data  input/output.  Prompting  is  provided  if  a response 
is  incorrect,  and  the  entry  HELP  or  ? will  provide  a message  detailing  the 
information  required.  Three  major  option  menus  are  provided:  DECREMENT, 
INCREMENT,  and  CONSOLIDATIONS.  Decrement  specifies  those  courses  that  are  to 
be  deleted;  Increment  specifies  those  courses  where  loads  or  lengths  are  to  be 
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modified;  Consolidation  specifies  courses  that  are  to  be  moved  from  one  location 
to  another  and  consolidated  with  existing  courses  at  the  new  location.  Sub-menus 
are  provided  to  aid  in  selection  of  the  actual  courses  to  be  involved  in  one  of 
the  above  three  actions.  The  first  sub-menu  allows  selection  of  all  courses  for 
a UIC,  or  just  a portion  of  the  courses.  The  second  sub-menu  allows  for  selection 
by  CDP,  CIN,  RMS  code,  or  course  type.  The  logic  in  Program  PARAM  insures  that 
all  data  are  requested  for  a desired  action,  and  that  invalid  options  will  not 
be  passed  on  to  Program  TRAM.  Several  actions  may  be  requested  for  a given  run. 

This  allows,  for  example,  consolidating  all  type  C courses  from  Activity  A to 
Activity  B,  and  all  $ type  F courses  from  Activity  A to  Activity  C in  one  run  for 
evaluation.  The  resultant  of  Program  PARAM  is  a group  of  control  parameters 
written  to  file  TRAM  PARM  that  will  control  the  TRAM  model  execution. 

Program  TRAM  is  called  to  execution  by  executive  TRAM,  which  is  initiated  when 
the  term  'TRAM'  or  'TRAM  I'  is  entered  on  the  NCSS  terminal.  From  this  point  on, 
execution  of  the  system  is  under  program  control,  with  all  necessary  interaction 
by  the  operator  preceded  by  a descriptive  PROMPT.  The  entry  of  'TRAM'  will  cause 
execution  of  the  entire  TRAM  system,  while  the  entry  'TRAM  I’  will  cause  execution 
of  the  system  to  terminate  following  printing  of  the  summary  of  the  instructor 
computation  results,  bypassing  the  cost  calculation. 

It  should  be  noted  that  file  TRAM  PARM,  that  is  created  by  Program  PARAM,  could 
be  set  up  manually  for  non-interactive  operation  of  the  TRAM  system  in  the  batch 
mode. 

PGM  TRAM.  This  Fortran  Language  program  is  the  heart  of  the  TRAM  system.  The 
basic  purpose  of  this  program  is  to  first,  analyze  the  parameters  transmitted 
from  Program  PARAM;  second,  access  the  courses  indicated  by  these  parameters 
from  the  NITRAS  master;  third,  make  the  necessary  actions  and  modifications  as 
indicated  by  these  parameters;  and  finally,  write  an  output  file  so  that  program 
ICALC  can  analyze  the  net  effect  on  instructor  requirements. 

The  logic  of  Program  TRAM  is  as  follows.  First,  seven  NITRAS  reference  tables 
are  read  in.  These  tables  allow  access  of  any  course  in  the  NITRAS  file  by 
certain  combinations  of  staff  UIC,  student  UIC,  CIN  number,  CDP  number,  RMS 
code,  or  course  type.  Next  the  parameter  file  from  Program  PARAM  is  read  and 
analyzed.  Incorrect  inputs,  such  as  invalid  UIC  codes,  are  flagged  at  this  time. 

Then  the  proper  action  is  taken.  If  the  courses  are  decrements,  they  are  written 
to  file  ICOMP  10  as  a decrement.  If  the  courses  are  increments,  they  are  written 
first  to  the  file  'AS  IS'  as  decrements,  then  the  requested  modifications  are 
made,  and  they  are  written  as  increments.  This  method  allows  the  total  instruc- 
tor requirements,  and  the  net  change  caused  by  this  action,  to  be  determined. 
Consolidations  are  somewhat  more  complex.  Basically,  all  courses  involved  in 
a consolidation  are  first  written  as  a decrement,  whether  at  a 'TO'  or  'FROM' 
location.  The  loads  are  then  allocated  to  the  receiving  locations.  If  the 
same  courses  exist  at  the  receiving  locations,  they  are  expanded  to  handle  the 
increased  load.  If  the  course  does  not  exist,  it  is  established  at  the  first 
receiving  location.  The  modified  courses  are  then  written  as  increments,  again 
allowing  computation  of  total  and  delta  instructor  requirements.  Many  such 
actions  can  be  cascaded;  Program  TRAM  cycles  until  all  such  actions  have  been 
disposed  of.  Program  TRAM  is  called  by  Executive  MODEL.  No  entry  is  normally  i 

required  to  start  this  executive,  as  it  is  automatically  called  by  Executive  TRAM. 

« 
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PROGRAM  ICALC.  This  PLl  program  accepts  the  NITRAS  and  calculated  data  from 
PGM  TRAM  for  each  affected  course,  and  calculates  the  changes  in  instructor 
requirements  resulting  from  the  user  input  request.  A major  facet  of  this 
program  is  the  application  of  default  options  to  handle  missing  data  situations 
in  the  NITRAS  data  base.  The  analyses  leading  to  the  establishment  of  default 
values  are  discussed  later  in  this  section. 

PGM  ICALC  is  called  by  ICOMP  EXEC  automatically.  No  user  intervention  is  re- 
quired. 

PGM  IFACE  (and  IFACEI).  This  FORTRAN  program  accepts  a sorted  output  of  PROGRAM 
ICALC  and  develops  an  interface  table  for  a COST  SUBROUTINE.  These  interface 
data  include  the  activity  UIC,  delta  instructors  and  AOB,  any  shortfall  in  train- 
ing capability  due  to  lack  of  capacity  at  an  activity,  and  the  year  to  be  con- 
sidered. IFACE  EXEC  calls  PGM  IFACE  which  in  turn  calls  COST  SUBROUTINE.  This 
FORTRAN  subroutine  calculates  officer  and  enlisted,  instructor  and  support 
personnel,  as  well  as  civilians  incremented  or  decremented  by  activity.  MPN  and 
O&MN  dollars  are  calculated  and  an  output  report  is  prepared  which  summarizes 
the  changes  in  resources  from  the  user-specified  action.  A TRAM  OUTPUT  file  is 
created  which  contains  detailed  reports  for  each  UIC  affected.  These  detail 
reports  can  be  accessed  through  PGM  DISPLAY  when  the  user  invokes  the  DISP  EXEC 
by  entering  the  term  'DISP'. 

PGM  IFACE  is  invoked  automatically  using  IFACE  EXEC.  The  user  has  the  option  of 
bypassing  the  cost  calculations  by  entering  TRAM  I and  MODEL  I in  place  of  TRAM 
and  MODEL  which  were  previously  discussed.  When  this  alternative  procedure  is 
followed,  IFACEI  EXEC  will  be  used  to  call  PGM  IFACEI.  Only  the  results  of  the 
instructor  computations  will  be  presented  under  this  option.  No  costs  will  be 
calculated. 

NITRAS  MASTER.  This  data  base  contains  over  4100  records  extracted  from  the 
Navy's  NITRAS  Master  Course  Reference  File.  Each  record  contains  247  fields 
of  data  which  describe  each  of  the  approximately  4000  courses  taught  by  CNET. 

Some  non-CNET  courses  are  also  described  in  this  file.  PGM  TRAM  accesses  the 
data  in  NITRAS  MASTER  in  responding  to  the  user  initiated  increment,  decrement, 
or  consolidation  requests.  The  data  stored  in  this  file  are  listed  in  Figure 
III-2. 


NUIC,  XUIC,  PCOST  MATRIX.  This  file  contains  three  separate  matrices  which  are 
accessed  by  PGM  IFACE  during  the  resource  calculation  process.  The  UIC  Matrix 
(NUIC)  contains  billet  (enlisted,  officer,  and  student)  and  civilian  ceiling 
point  data  for  each  CNET  UIC.  The  data  contained  in  this  file  are  outlined 
in  Figure  III-3.  The  Exception  UIC  Matrix  (XUIC)  contains  a list  of  UIC's 
which  require  special  handling  during  the  resource  calculation.  Special  process 
directing  flags,  as  well  as  information  contained  in  the  output  reports,  are 
included  in  this  file.  Its  contents  are  described  in  Figure  III-4.  The  Per- 
sonnel Cost  Matrix  (PCOST)  contains  standard  cost  factors  used  in  the  final 
resource  calculation;  its  content  is  listed  in  Figure  III-5. 

NITRAS  REFERENCE  TABLES.  Seven  tables  are  read-in  by  program  TRAM.  These 
tables  are  used  to  provide  access  to  specific  records  in  the  NITRAS  file 
without  the  necessity  of  reading  all  4100  plus  courses  in  the  file.  Thus,  a 
decrement  of  all  C7  courses  can  be  accomplished  by  merely  looking  in  a core 
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NITRAS  MCRF  EXTRACT  FORMAT  PHt  i 


RECOfID 

POSITION 

DATA  NAME 

LEN 

TYPE 

M/0 

VALUE/COMMENTS 

1-4 

COP 

4 

AN 

FI 

5-12 

CIN 

8 

AN 

FI 

13-28 

COURSE  SHORT  TITLE 

16 

AN 

FI 

29-32 

NOBC 

4 

AN 

FI 

33-36 

NEC 

4 

AN 

FI 

37-39 

OFF.  CRS.  CODE 

3 

AN 

FI 

40-44 

PRIORITY  DES 

5 

AN 

FI 

45-40 

RMS  COST  CODE 

4 

AN 

FI 

49-50 

TYPE  COURSE 

2 

AN 

FI 

51 

SVC  SUPP 

1 

AN 

FI 

52 

METHOD  INST. 

1 

AN 

FI 

53-67 

FILLER 

15 

AN 

FI 

68 

DEPT-CODE 

1 

AN 

FI 

69-71 

FILLER 

3 

AN 

FI 

72 

STATUS-CODE 

1 

AN 

FI 

73-75 

STATUS- DATE 

3 

P 

F2 

S9(5)  COMP-3 

76-83 

PREREQ-CIN 

8 

AN 

F3 

84-B5 

EST.  ATTR.  RATE 

2 

P 

F4 

S99V9  COMP-3 

86-87 

EST.  SETBK.  RATE 

3 

P 

F5 

S99V9  COMP-3 

88-90 

THEORY  HRS. 

3 

P 

F6 

S9(5)  COMP-3 

91-93 

LAB  HRS. 

3 

P 

F7 

S9(5)  COMP-3 

94-96 

FILLER 

3 

AN 

F8 

97 

TRAPS  IND. 

1 

AN 

F8 

98-102 

TPC 

5 

AN 

F8 

103-107 

STU.  UlC 

5 

AN 

F8 

108-112 

STAFF  UlC 

5 

AN 

FB 

113-140 

CRS  CONTACT  HRS 

28 

17k) 

ICONTACT  RATIO 

2 

P 

F9A(7) 

S99  COMP-3 

jcONTACT  HOURS 

2 

P 

F9B(7) 

S999  COMP-3 

141-143 

TOTAL  CONTHRS 

3 

P 

FIO 

S0(6|  COMP-3 

144 

CFY-CROSSUTIL 

1 

AN 

F11A 

145-147 

CFY-CRS  LENGTH 

3 

P 

F12 

S9(5|  COMP-3 

148-150 

CFY-CLASS  FREQUENCY 

3 

P 

F12 

151  153 

CFY-PERS INPUT 

3 

P 

F12 

154  156 

CFY-PEHSFREQ 

3 

P 

F12 

157-159 

CFY-EQUIP  INPUT 

3 

P 

F12 

IGO  16? 

CFY-EQUIP  FREQ 

3 

P 

F12 

163-165 

CFY-SPACE  INPUT 

3 

P 

F12 

166-168 

CFY-SPACE  FREQ 

3 

P 

F12 

169-183 

FILLER 

15 

F11B 

FIGURE  III-2 
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I 

t 


RECOAO 

POSinoW  DATA  NAME  LEN  TYPE  M/0  VALUE/COMMENTS 


L 

184  -223 

FY+1  CAPACITIES 

same  as  Col.  144-183 

224-263 

FY*2  CAPACITIES 

same  as  Col.  144-183 

264  -266 

CFY  OF  PLAN-USN 

3 

p 

S9(5|  COMP-3 

267-269 

CFY  OF  PLAN-USNOB 

3 

p 

270-272 

CFY  OF  PLAN-USNR 

3 

p 

1 

273-275 

CFY  OF  PLAN-USNRR 

3 

p 

276-278 

CFY  OF  PLAN-USMC 

3 

p 

1 

279-281 

CFY  OF  PLAN-USCG 

3 

p 

[ 

282-  284 

CFY  OF  PLAN-USA 

3 

p 

' 

285  28/ 

CFY  OF  PLAN-USAF 

3 

p 

288-290 

CFY  OF  PLAN-NATG 

3 

p 

291-293 

CFY  OF  PLAN-FORNAT 

3 

p 

i 

294-296 

CFY  OF  PLAN-DOD 

3 

p 

[ 

297-299 

CFY  OF  PLAN-NOOD 

3 

p 

1 

300-302 

CFY  OF  PLAN-WOM 

3 

p 

f 

303-341 

CFY  ENPLAN 

39 

n 

[, 

342-380 

FY+1  OF  PLAN 

36 

1 

1. 

381-419 

FY+1  ENPLAN 

39 

\ 

\ 

420-458 

FY+2  OF  PLAN 

39 

459-497 

FY+2  EN  PLAN 

36 

These  fields  are  all  formatted 

i 

498-536 

FY+3  OF  PLAN 

39 

the  same  as  CFY  OF  PLAN 

i. 

537-575 

FY+3  EN  PLAN 

39 

in  Coi.  264-302 

\ 

576-614 

FY+4  OF  PLAN 

36 

(13  S9(5|  C0MP-3J 

F 

615-653 

FY+4  EN  PLAN 

39 

1 

654  - 692 

FY+5  OF  PLAN 

39 

r 

693-731 

FY+5  ENPLAN 

39 

t; 

732  -/70 

FY+6  OF  PLAN 

39 

[- 

771  809 

FY+6  ENPLAN 

39 

[ 

810 

FILLER 

L 1 

i 

FIGURE 

III-2 

(Cont'd) 
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UlC  MATRIX  FORMAT 


RECORD 

POSITION  DATA  NAME  LEN  _ 


I- 5 
6-10 

II- 15 
16-41 
42-46 
46-49 
50-53 
54-57 
58-61 
62-65 
66-69 
70-73 
74-77 
78-81 
82-85 

86- 89 

87- 93 
94-97 
98-103 
104-109 
110-113 
114-122 
123-131 
132-140 
141-149 
150-158 
159-167 
168 

169 

170 

171 

172 

172-176 

177-179 

180-187 

188-191 

192-194 

196-202 

203-206 

207-209 

210-217 

218-221 

222-224 

225-232 

233-236 

237-239 

240-247 


PARENT  UlC  S 

ACTIVITY  UlC  5 

STUDENT  UlC  5 

ACTIVITY  NAME  26 

CFY  TOTAL  OFFICER  BILLETS  4 

CFY  OFF  INSTRUCTOR  BILLETS  4 

CFY  TOTAL  ENLISTED  BILLETS  4 

CFY  ENL  INSTRUCTOR  BILLETS  4 

CFY  CIVILIANS  4 

FY1  TOTAL  OFFICER  BILLETS  4 

FY1  OFF  INSTRUCTOR  BILLETS  4 

FY1  TOTAL  ENLISTED  4 

FY1  ENL  INSTRUCTOR  BILLETS  4 

FY1  CIVILIANS  4 

CFY  OFF  STUDENT  BILLETS  4 

CFY  ENL  STUDENT  BILLETS  4 

FY1  OFF  STUDENT  BILLETS  4 

FY1  ENL  STUDENT  BILLETS  4 

CFY  AOB  6 

FY1  AOB  6 

MULTIPLIER  (INSTR  COMP  ADJ)  4 

CFY  CIVILIAN  LABOR  BUDGET  9 

CFY  TOTAL  OSiMN  BUDGET  9 

CFY  REIMBURSABLES  BUDGET  9 

FY1  CIVILIAN  LABOR  BUDGET  9 

FY1  TOTAL  O&MN  BUDGET  9 

FY1  REIMBURSABLES  BUDGET  9 

FLAG1  1 

FLAG2  1 

FLAG3  - DETACHMENT  1 

FLAG4  1 

FLAG5  1 

PER  CAPITA  DIRECT  MIL  PERS  4 

PER  CAPITA  DIRECT  CIV  PERS  3 

PER  CAPITA  DIRECT  OTHER  COSTS  8 

PER  CAPITA  ACTY  SUP  MIL  PERS  4 

PER  CAPITA  ACTY  SUP  CIV  PERS  3 

PER  CAPITA  ACTY  SUP  OTHER  COSTS  8 

PER  CAPITA  HOST  SUP  MIL  PERS  4 

PER  CAPITA  HOST  SUP  CIV  PERS  3 

PER  CAPITA  HOST  SUP  OTHER  COSTS  8 

PER  CAPITA  DIRECT  TRNG  MIL  PERS  4 

PER  CAPITA  DIRECT  TRNG  CIV  PERS  3 

PER  CAPITA  DIRECT  TRNG  OTHER 

COSTS  8 

PER  CAPITA  SUPPORT  MIL  PERS  4 

PER  CAPITA  SUPPORT  CIV  PERS  3 

PER  CAPITA  SUPPORT  OTHER  COSTS  8 


AN 

AN 

AN 

AN 


F4.1 


VALUE/COMMENTS 


B99V.9(deciinal  anunMd) 


FIGURE  1 1 1-3  NUIC  MATRIX  DATA  ELEMENTS 


/ 


J 


TAHb  KtPUKT  NO.  37 

EXCEPTION  UlC  MATRIX  FORMAT 


RECORD 

DATA  NAME LEN  TYPE  VALUE/COMMENTS 


1-5 

6-7 

8-12 

13-52 

53 

54-57 

58 

59-66 

67-124 


EXCEPTION  UlC  5 

NUMBER  UlC'S  TO  CONSIDER  2 

OTHER  UlC'S  TO  CONSIDER  NO.  1 5 

OTHER  UlC'S  TO  CONSIDER  NO.  2-9  40 

EXCEPTION  CODE  FLAG  NO.  1 1 

EXC  CODE  FLAGS  2-5-GENERAL  UlC  FLAGS  4 

EXCEPTION  CODE  FLAG  NO.  6 1 

EXC  CODE  FLAGS  7-14-FOR  OTHER  UlCS 

TO  CONSIDER  FIELDS  (9)  9 

COMMENTS  58 


AN 

I 

AN 

AN  5 Pos.  per  UlC  Field 

I See  Below 

I See  Below 

I See  Below 

I See  Below 


EXCEPTION  CODE  FLAGS 

1— 0  Follow  normal  processing.  If  IPUIC'IAUIC,  then  all  acthritias  with  same 

PUIC  (including  OETS)  will  be  summed  and  operated  upon  as  a single  unit. 

1 Causes  Exception  Code  Flag  2 to  be  chedcad. 

2— 0  Causes  activities,  where  PUIC'AUIC  which  would  normally  bo  summed  for  all 

equal  PUIC's,  to  be  treated  as  a single  activity.  Summing  of  equal  PUIC't 
would  not  be  performed. 

1 Causes  FLG3  in  the  NUIC  MATRIX  to  be  checked  during  the  summing  of 

all  equal  PUIC's.  DETS  with  FLG3>1  will  not  be  included  in  the  summing 
process.  The  objective  is  to  sum  only  those  UlC's  physically  located  at  one 
site. 

3— 5  Additional  flags  for  controlling  general  process  logic  sequencing.  These  are 

unused  at  the  present  time. 

6-14  These  nine  flags  are  intended  for  assignment  to  each  of  the  nine  possible 

UlC's  in  the  TO  BE  CONSIDERED'  fields  of  the  XUIC  MATRIX.  They 
may  be  used  to  designate  a UlC  as  a Host,  DET,  etc.  They  ere  unused 
at  the  present  time. 


FIGURE  1 1 1-4  XUIC  MATRIX  DATA  ELEMENTS 
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PERSONNEL  COST  MATRIX 


RECORD 

POSITION 

DATA  NAME 

LEN  TYPE  VALUE/COMMENTS 

1-5 

COST/OFFICER  BILLET 

5 

1 24000 

FY77 

6-10 

COST/ENLISTED  BILLET 

5 

1 11000 

FY77 

11-15 

COST/STUDENT  BILLET 

5 

1 None 

Available 

16-20 

COST/OFFICER  STUDENT 
BILLET 

5 

1 24000 

FY77 

21-25 

cost/Enlisted  student 

BILLET 

5 

1 11000 

FY77 

26-30 

TRAVEL  COST/OFFICER 

5 

1 03007 

FY77 

31-35 

TRAVEL  COST/ENLISTED 

5 

1 02221 

FY77 

36-40 

COST/CIVILIAN  CEILING 

POINT 

5 

1 19000 

FY77 

41-45 

COST/RIF 

5 

1 09300 

FY77 

45-50 

TRAVEL  COST/CIVILIAN  CP 

5 

1 06000 

FY77 

51-80 

NOT  USED 

30 

1 ZERO'S 

FIGURE  1 1 1-5  PCOST  MATRIX  DATA  ELEMENTS 
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resident  table  for  the  location  of  all  courses  in  the  file  meeting  this  criterion 
(in  this  case,  37  courses).  This  greatly  reduces  I/O,  increases  speed,  and 
reduces  cost  of  model  execution  by  several  magnitudes.  Also,  to  save  computer 
I/O  execution  costs,  these  tables  are  read  into  the  core  using  unformatted  I/O. 

OTHER  PROGRAMS.  Several  auxiliary  programs  and  executives  were  developed  to 
make  the  model  generated  information  more  accessible  to  the  user.  The  LOOK 
EXEC  and  PGM  TST  have  been  provided  so  that  the  user  can  review  specific  courses 
of  interest  in  the  NITRAS  MASTER  file.  Access  is  provided  by  COP,  CIN,  Staff  or 
Student  UIC. 

The  ICOMPIO  EXEC  and  PGM  LISTIC  allow  the  user  to  create  a listing  of  the  in- 
structor computations  from  PGM  ICALC  for  each  course  (COP)  involved. 

The  DISP  EXEC  and  PGM  DISPLAY  are  used  to  access  the  detail  level  reports  created 
from  the  COST  SUBROUTINE  within  PGM  IFACE.  The  user  enters  the  term  'DISP'  to 
invoke  this  program  after  which  individual  pages  or  UIC  reports  can  be  selected. 

TRAM  FUNCTIONAL  SPECIFICATION 

Preliminary  functional  specifications  were  developed  and  evaluated  with  CNTECHTRA 
and  TAEG  in  the  December  1975  to  April  1976  period.  Section  II  of  this  report 
described  the  steps  in  the  functional  analysis  leading  to  the  Functional  Speci- 
fication.- The  specification  became  the  framework  for  the  TRAM  design  and  develop- 
ment phase.  However,  a number  of  compromises  had  to  be  made  because  of  the 
availability  and  nature  of  the  data  planned  as  a TRAM  input.  Some  of  the 
compromises,  however,  were  offset  by  more  thorough  analyses  of  the  data,  which 
permitted  defaults  for  missing  data  to  be  incorporated  into  the  model.  The 

following  outlines  the  general  functional  specification  for  TRAM. 

OBJECTIVES.  The  TRAM  model  is  to  be  a high  level  system  designed  to  rapidly 
assess  resources  attached  to  increments,  decrements,  feasibility  studies,  and/or 
Program  Budget  Decisions  (PBD)  at  the  Functional  Command  or  CNET  level.  The 
thrust  of  the  TRAM  model  will  be  to  merge  the  technologies  of  previous  models 
and  develop  a new  model  for  resource  planning  and  management.  TRAM  will  test 
the  concept  of  providing  information  for  advanced  planning  of  available  resources 
required  to  meet  training  demands,  for  the  next  fiscal  year  and  the  several  "out 
years",  on  an  aggregate  level  or  individual  course  basis.  The  model  will  test 
the  feasibility  of  meeting  planned  training  loads  with  available  resources, 
calculate  resources  required  to  meet  shortfalls,  indicate  resource  surpluses, 
and  aggregate  these  totals  on  a training  center  (UIC)  basis.  The  training 
manager  will  receive  an  indication  of  the  problem  areas  and  overall  effective- 
ness of  this  application  of  resources  through  the  initial  run(s)  of  the  TRAM 
model.  The  user  can  then  test  the  effect  of  new  or  modified  strategies  through 
additional  model  runs.  A major  thrust  of  the  TRAM  effort  will  be  aimed  at  the 
portion  of  the  model  that  permits  the  baseline  conditions  to  be  modified  to 
simplify  the  user/model  interface. 


PROPOSED  METHODS  AND  PROCEDURES.  The  TRAM  model  is  intended  for  use  by  train- 
ing management  and  staff  personnel  at  the  Functional  Command  or  CNET  level  in  j 
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order  to  seek  more  optimal  use  of  training  resources  in  the  accommodation  of 
requested  training  loads.  The  personnel  using  the  model,  and  the  specific 
conditions  under  which  it  will  be  used,  will  vary.  However,  the  following 
generalizations  can  be  made. 

1.  Decision  points  where  the  model  may  be  used.  The  following 
primary  decision  points,  as  outlined  by  CNTECHTRA,  indicate 
various  key  points  in  their  planning  process  where  the  TRAM 
model  might  prove  useful. 

a)  Requirements  Planning 

0 Increment/decrement  planning 

0 Development  and  integration  of  student  quotas 

0 Analysis  of  the  effects  of  attrition  on  the 
training  command 

0 Analysis  of  new  programs 

0 Evaluation  of  plans  to  reduce  rate/rating/NEC 

shortages. 

b)  Determination  of  Annual  Training  Rate  Feasibility,  with: 

0 Current  manpower  authorized 

0 Current  manning  load 

0 Current  equipment/space  limitations 

c)  Decision  Related  to  Infeasibilities 
0 Mix  of  courses 

0 Elimination  of  courses 

0 Reduction  in  course  lengths 

0 Optimum  trade-offs. 

d)  Optimization  of  Established  Programs 

0 Cross-utilization  of  instructors 

0 Mix  of  convening  frequency  and  class  size. 

e)  Personnel  Requirements 

o Instructor  requirements 

0 Support  (non-instructor)  requirements 

0 Flexibility  in  meeting  peak  demands. 


I)  Activity  or  Course  Cotiso I idatlons  ("what  Ifs") 


2.  Typical  Management  Applications 

Training  managers  are  expected  to  derive  a number  of  benefits  from 
model  use.  These  benefits  may  be  better  understood  by  treating 
them  within  the  context  of  potential  problems  and  questions  that 
training  managers  may  use  the  model  to  investigate.  The  overriding 
expected  benefit  is  to  improve  the  utilization  of  training  resources. 
Some  typical  input  questions  to  TRAM  might  be: 

a)  What  is  the  effect  of  closing  a training  center? 

To  close  a training  center,  the  load  currently  taught  at 
that  center  must  be  transferred  to  other  facilities.  The 
model  will  re-program  students  from  courses  currently  taught 
at  that  center  to  the  same  courses  taught  at  other  locations. 

The  model  user  must  then  indicate  a disposition,  such  as 
noting  a training  center  that  must  absorb  the  shortfall  or 
establish  the  courses  not  taught  elsewhere.  The  model 
would  then  calculate  resource  requirements  and  training 
loads  at  each  of  the  training  centers  affected  for  compari- 
son with  baseline  conditions.  In  this  way,  rapid  compari- 
sons can  be  made  for  alternate  strategies,  including  the 
potential  benefits  in  closing  a center. 

b)  What  additional  resources  are  required  to  eliminate  a shortage 
in  trainees  with  a specific  NEC? 

Typically,  SUPERS  identifies  shortages  in  a specific  NEC  and 
requests  a training  load  that  may  not  be  immediately  accommo- 
dated, so  the  load  is  usually  spread  over  several  years.  Under 
certain  conditions,  it  is  desirable  to  accommodate  this  demand 
in  a shorter  time  period.  By  indicating  the  required  dentand, 
the  model  will  calculate  the  resources  required  to  meet  this 
demand,  and  upon  comparison  with  the  baseline,  indicate  the 
new  resources  to  meet  this  peak  demand. 

3.  Primary  Inputs 

Three  primary  inputs  with  a multiplicity  of  attributes  have  been 
defined  for  the  TRAM  model. 

a)  Resource/Capacity/Planned  Requirements  - This  input  is  directly 
from  the  NITRAS  MCRF  file  and  includes  course  numbers,  names, 
capacities,  schedules,  resource  requirements  and  planned  train- 
ing loads.  These  data  will  form  the  baseline  for  calculating 
instructors  and  support  requirements,  based  on  schedules  and 
loads,  for  courses  and  training  centers. 
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b)  Personnel  Data  - This  input  defines  authorized  billets  at  each 
CNET  activity  for  the  current  and  one  out  year.  Data  for  FY+2 
to  FY+6  were  eliminated  for  this  model  due  to  potential  security 
classification  problems.  These  data  are  available  from  the 
1000/2  files.  Other  inputs  include  civilian  ceiling  points  and 
personnel  from  other  services  serving  at  a CNET  activity. 

c)  Cost/Resource  Data  - This  input  currently  comes  from  data  con- 
tained in  the  Per  Capita  Cost  System.  It  is  used  to  estimate 
the  dollar  value  applied  to  model  calculations,  and  to  provide 
some  insight  into  an  activity's  operation. 

4.  Primary  Outputs 

Four  model  outputs  have  been  defined. 

a)  Instructor  Resources  - This  output  identifies  the  instructor 
requirements,  on  a course  basis  or  aggregated  on  a training 
center  basis,  as  calculated  using  the  formulas  outlined  in 
CNTECHTRA  Instruction  5311.1A,  Change  2.  These  instructor 
requirements  may  be  based  on  the  course  running  at  (a) 
planned  load,  (b)  100%  load,  or  (c)  requested  but  infeasible 
load. 

b)  Support  Requirements  - This  output  defines  the  numbers  of 
support  personnel  required  to  meet  the  planned  training 
load  and  is  aggregated  by  training  center  (UIC).  The  values 
calculated  as  far  as  possible  will  be  based  on  empirical 
relationships  applied  at  CNTECHTRA,  and  augmented  by  data 
contained  in  the  UIC  input. 

c)  Throughput  - This  output  quantitatively  defines  student 
throughput,  aggregated  by  training  center  or  by  rating/NEC. 

This  value  gives  the  actual  training  load  that  can  be 
accommodated  with  currently  available  resources,  or  the 
training  load  that  would  result  should  the  requested  load 
be  accommodated.  This  throughput  is  not  a projection,  but 
rather  is  based  on  planned  loads. 

d)  Resource  Sensitivity  - This  output  is  available  for  certain 
runs  and  gives  the  instructor  and  support  requirements  of 

a training  center  for  various  levels  of  loading.  It  is 
useful  for  determining  optimum  loading  and  anticipating  the 
effects  of  increments/decrements. 

DATA  SUPPORT  AND  ANALYSIS.  TRAM  is  dependent  upon  four  primary  sources  of 
data  in  order  to  operate: 

1)  NITRAS  Master  Course  Reference  File 

2)  1000/2  Manpower  Authorization 
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3)  Civilian  Ceiling  Points 

4)  Resource  Management  System  (RMS)  Per  Capita  Cost  and  Budget  Data. 

Extracts  of  Navy  data  bases  containing  the  above  data  were  requested  in  April 
1976.  Certain  RMS  data  requested  from  CNET  were  not  made  availabe  due  to 
their  potential  sensitivity;  civilian  data  were  received  too  late  for 
incorporating  into  the  automated  process,  therefore  they  were  entered  manually 
from  hard  copy  sources. 

NITRAS.  A primary  source  of  data  for  TRAM  is  NITRAS.  An  extract  of  the  actual 
MCRF  data  was  made  for  247  fields,  which  is  only  a fraction  of  the  data  in 
the  MCRF.  The  layout  of  the  data  extracted  was  shown  in  Figure  III-2.  Much 
analysis  of  these  data  was  required  before  it  could  be  used  to  support  a model 
run.  First,  a few  of  the  UIC  codes  were  in  error  or  inconsistent,  and  these 
were  modified.  Next,  the  data  were  "washed"  through  several  processes  to 
ascertain  their  compatibility  with  model  processing.  This  is  not  to  say  that 
the  data  were  bad.  Rather,  the  NITRAS  file  is  designed  to  support  an  informa- 
tion processing  system,  not  a TRAM  model.  In  its  proper  role,  if  a planned 
load  is  not  available  it  should  be  left  blank.  However,  if  it  is  to  be  used 
as  a model  input,  some  estimate  or  default  should  be  used  to  assure  proper 
model  operation.  Likewise,  a number  that  may  be  blatantly  wrong  in  NITRAS  may 
have  no  material  effect,  as  that  field  is  not  used  for  calculations,  while  that 
same  error  might  totally  invalidate  TRAM  results  if  it  is  used  as  an  input. 

One  of  CNTECHTRA's  primary  concerns  is  to  provide  enough  qualified  personnel 
to  teach  or  instruct  its  training  load.  Thus,  the  primary  use  of  NITRAS  was 
to  calculate  instructor  requirements  based  on  the  standard  formula,  and  course 
characteristics  and  student  loads  from  NITRAS.  Several  analyses  were  made  of 
the  NITRAS  data  to  ascertain  how  effective  this  automated  instructor  computation 
might  be  and  how  the  validity  could  be  improved.  The  first  problem,  and  one 
that  recurred  with  every  data  source  throughout  this  study  was  the  problem  of 
applying  data  to  applications  for  which  they  were  not  intended.  For  example, 
NITRAS  carries  the  course  length  in  days  (as  AOB  is  counted  in  days  elapsed, 
not  instructional  days)  while  the  instructor  computation  requires  weeks  (or 
fractions).  This  field  had  to  be  converted.  The  first  analysis  was  to  determine 
"fatal"  errors.  These  consist  of  errors  for  which  no  redundant  data  exist  or 
defaults  cannot  be  made  with  any  degree  of  certainty.  The  types  and  numbers 
of  errors  generated  during  this  analysis  are  as  follows: 
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NITRAS  INVALID  AND  MISSING  DATA 
PREVENTING  INSTRUCTOR  COMPUTATION 
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TOTALS  FOR  ALL  COURSES 
498  75  19  304 


895 


866 


252 


TOTALS  FOR  CNET  COURSES 

3842  1504  212  397  53  14  242  815  652  219 

The  one  element  the  model  cannot  correct  for  is  missing  planned  load  data.  It 
was  determined  that  in  most  cases  a zero  load  indicated  this  figure  was  unavail- 
able; thus,  the  missing  data  are  valid.  As  can  be  seen,  a surprisingly  low 
number  of  courses  contain  "fatal"  errors,  and  it  was  felt  that  this  was  well 
within  acceptable  limits. 


Next,  several  analyses  were  made  to  determine  default  and  tolerable  limit  values. 
The  first  analysis  was  to  graph  course  lengths,  both  to  show  the  range  of  lengths 
to  be  encountered,  and  to  list  in  general  form  the  validity  of  the  data.  See 
Figure  III-6. 


Most  courses  greater  than  a few  days  are  in  multiples  of  weeks.  As  courses 
are  listed  in  calendar  days,  lengths  of  5,  12,  19,  26,  33,  ...,  describe  even- 
week  courses.  The  graphical  presentation  shows  that  the  bulk  of  the  courses 
follow  this  pattern.  However,  23  courses  are  loaded  showing  a length  of  14 
days,  indicating  a course  ending  on  a Sunday,  which  is  not  likely.  More  likely, 
the  data  were  loaded  incorrectly,  and  can  be  compensated  for  by  considering  any 
12,  13  or  14-day  course  as  a two-week  course,  and  so  on.  Using  this  logic, 
course  lengths  can  be  made  compatible  with  model  input  requirements. 


The  second  analysis  was  of  S/I  ratios.  Only  recently  was  this  field  added  to 
NITRAS  and  loading  is  not  yet  complete.  An  analysis  of  these  S/I  ratios  is 
shown  in  Figure  III-7.  The  implications  of  this  analysis  are  shown  in  four 
graphs.  Figures  III-8  through  III-ll.  As  can  be  seen,  S/I  ratios  are  fairly 
consistent  if  courses  are  separated  by  type.  Three  sets  of  defaults  were 
calculated,  based  on  the  results  of  this  study.  These  defaults  are: 
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STUDENT  / INSTRUCTOR  RATIO 
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NO.  37 

A COURSES 

C COURSES 

F COURSES 

Ratio 

% Mrs. 

Ratio 

% Mrs. 

Ratio 

% Mrs. 

50 

1.3 

50 

0.4 

50 

1.8 

25 

54.6 

25 

26.6 

25 

25.2 

16 

8.3 

12 

4.8 

12 

14.2 

12 

9.6 

8 

6.7 

8 

8.5 

8 

7.5 

6 

17.0 

6 

18.7 

6 

11.8 

4 

28.5 

4 

14.3 

4 

7.0 

2 

16.0 

3 

17.3 

f These  default  values  are  slightly  raised  so  that  minor  course  overloads  will 

not  result  in  an  excessive  number  of  instructor  requirements  being  generated. 

Next,  the  average  length  of  a teaching  day  was  calculated,  and  is  shown  below: 

I;  # COURSES  AT  VARIOUS  HRS/DAY  (LOCK  STEP  COURSES) 


1 - 

2 

1 

2 - 

3 

9 

3 - 

4 

39 

4 - 

5 

41 

5 - 

6 

238 

6 - 

7 

2205 

7 - 

8 

400 

8 - 

9 

83 

9 - 

10 

22 

10  - 

11 

12 

11  - 

12 

7 

12  - 

13 

11 

13  - 

14 

5 

14  - 

15 

2 

15  - 

16 

2 

16  - 

17 

1 

19  - 

20 

1 

26  - 

27 

1 

30  - 

31 

1 

31  - 

32 

2 

35  - 

36 

1 

42  - 

43 

1 

99  - 

100 

1 

{ ^ 


AVG  HRS/TEACHING  DAY  = 6.45  NUMBER  OF  COURSES  IN  SAMPLE  = 2843 
The  average  value,  6.45,  was  used  without  further  analysis. 


Further  analysis  was  made  of  maximums,  minimums,  and  averages  for  course 
lengths,  convenings,  loadings,  etc.,  to  determine  norms  for  model  operation 
and  to  allow  data  error  detection  and  correction  by  use  of  defaults. 


This  analysis  is  too  large  to  be  included  in  this  report.  The  full  analysis 
is  contained  in  the  listings  section  of  TAFG  Technical  Memorandum  76-3. 
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lijsocl  on  this  (inalysis,  the  only  data  corr(?cLion  made  to  NITRAS  involved  the 
rhanqes  in  DIG  codes  described  previously. 

1000/2  ANALYSIS.  The  1000/2  Manpower  Authorizations  contain  the  authorized  and 
projected  billet  information  for  all  activities.  The  1000/2  data  were  extracted 
for  two  fiscal  years  for  all  CNET  activities,  deleting  most  out-year  data  due  to 
a security  classification  problem.  The  format  of  these  data  is  shown  in  Figure 
III-12. 

As  was  the  case  with  other  data  sources,  enough  inconsistency  existed  in  data 
and  data  formats  to  substantially  complicate  the  computer  processing.  First, 
officer  and  enlisted  files  contain  slightly  different  formats,  so  they  cannot 
be  automatically  merged.  Second,  the  UIC  codes  are  not  totally  consistent  with 
NITRAS,  complicating  an  automatic  comparison.  (The  same  is  true  with  1000/2  vs. 
RMS.)  Third,  the  billet  information  is  not  coded  in  a form  that  permits  a com- 
puter to  perform  a job  analysis  study.  Finally,  not  all  personnal  at  an  activity 
are  included  (civilians.  Marines,  other  services,  etc.)  On  the  1000/2  tape, 
one  form  of  automatic  analysis  was  possible  - the  determination  of  instructor 
billets.  Various  combinations  of  searches  basec*  on  NEC's,  NOBC's,  and  the  words 
INST  or  INSTR  with  various  leading  and  trailing  characters  allowed  extraction 
of  instructor  billets  with  a greater  than  99%  confidence  factor.  The  data 
extracted  included  officer  and  enlisted  billets  by  activity  (including  average 
grade),  instructor  billets  (officer  and  enlisted),  and  student  billets.  The 
results  of  this  detailed  analysis  are  contained  in  the  computer  listings  of  TAEG 
Technical  Memorandum  76-3. 

ANALYSIS  OF  RMS  COST  DATA.  One  objective  in  the  development  of  TRAM  was  to  have 
the  capability  of  assigning  costs  to  resource  deltas  calculated  during  a model 
run.  A magnetic  tape  detailing  costs  by  RMS  cost  account  was  obtained  from 
Code  N-5  of  CNTECHTRA.  The  detail  cost  data  were  summarized  into  three  major 
categories  for  each  training  UIC.  Figure  1 11-13  is  an  example  of  a UIC  summary 
and  shows  the  three  categories: 

1)  Command  and  Staff  - Represents  cost  accounts  with  a distribution 
code  of  0000100  (OH-1).  Generally,  only  a single  detail  account 
contained  all  of  the  data  in  this  category.  Training  Center 
Command,  e.g.,  C.O.,  X.O.,  etc,  and  Staff,  e.g..  Personnel, 
Administration,  etc.,  are  included. 

2)  Support  - Contains  all  non-mission  related  resources  which  the 
activity  consumes  in  support  of  other  base  functions,  e.g.. 

Public  Works,  Supply,  etc.  Cost  accounts  with  distribution 
codes  0999100,  i.e..  Excluded  Costs  less  the  costs  included  in 
the  Commano  and  Staff  - ACTY  SUPPORT  category,  are  contained 
in  this  classification. 

3)  Direct  Training  - Contains  all  direct  training  costs  including 
Division  (OH-3)  and  Department  (OH-2)  cost  accounts.  Distribu- 
tion codes  of  XXXX7XX  (Direct),  XXXX500  (OH-3),  and  XXXX300  (OH-2) 
are  summarized  into  this  category. 
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Military  and  Civilian  Labor  Hours  were  divided  by  2080  lIRS/YEAR  to  calculate 
the  equivalent  personnel  at  the  activity.  It  had  been  anticipated  that  these 
data  could  be  used  for  apportioning  1000/2  billets;  however,  because  of  major 
discrepancies  in  Military  Labor  reporting,  this  approach  was  abandoned  in 
favor  of  a more  direct  analysis  of  the  1000/2  report. 

The  major  resource  delta  calculated  by  TRAM  is  billets/ceiling  points. 
CNTECHTRA  applies  standard  rates  to  officer,  enlisted,  and  civilian  positions; 
therefore,  RMS  calculations  of  Military  $/HR  or  Civilian  $/HR  are  not  used  by 
the  model.  The  O&MN  costs  (excluding  Civilian  Labor),  however,  can  be  appor- 
tioned on  increment/ decrement  exercises  to  reflect  the  change  from  a specific 
"what  if"  action.  The  initial  approach,  based  upon  discussions  with  RMS 
personnel  was  to  be: 

1)  If  the  change  is  less  than  10%,  no  O&MN  resources  could  be 
impacted  (other  than  the  direct  calculation  of  civilians  by 
the  standard  rate  formula). 

2)  On  a disestablishment,  an  elimination  of  the  full  O&MN  budget 
would  be  made.  Other  add-back  costs  will  be  calculated 
independently. 

3)  From  a 10%  to  a 100%  change,  a non-linear  function  (to  be 
determined)  would  be  applied  to  calculate  the  O&MN  dollars 
to  be  removed  or  added. 

The  preliminary  algorithms  approximating  these  assumptions  are: 

1)  If  80%  or  more  of  instructor  personnel  are  eliminated  from  an 
activity,  all  personnel  and  all  O&MN  budget  dollars  are  elimin- 
ated. 

2)  If  the  change  in  instructor  personnel  is  50%  or  less  of  the 
total  instructors  at  an  activity,  support  personnel  and  O&MN 
dollars  are  removed  at  a rate  equal  to  40%  of  the  change 
percentage;  i.e.,  only  20%  would  be  eliminated  on  a 50% 
instructor  change  (.40  x .50). 

3)  If  the  change  in  instructor  personnel  is  between  50%  and 
80%,  support  personnel  and  O&MN  dollars  are  removed  at  a 
rate  equal  to  60%  of  the  change  percentage  over  50%. 

Therefore,  a 60%  change  in  instructors  would  produce  a 36% 
change  in  support  and  O&MN  resources,  a 70%  change  would 
be  52%,  etc.  Beyond  80%,  assumption  1)  takes  precedence. 

4)  Algorithms  similar  to  2)  and  3)  also  are  applied  to  incre- 
ments. 

SUMMARY  OF  MODEL  DEVELOPMENT.  The  TRAM  development  effort  fell  into  two 
major  categories  - data  processing  and  logic  formulation.  Because  of  the 
importance  of  data  to  TRAM  operation,  this  was  a major  preoccupation  during 
the  development  cycle.  The  NITRAS  analyses  led  to  usable  default  logic 
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capable  of  correcting  nearly  85%  of  the  missing  or  invalid  NITRAS  data.  This 
permitted  extremely  accurate  calculations  of  instructor  requirements  where 
course  changes  are  concerned.  Two  other  aspects  of  the  data  - support  person- 
nel and  costs  - were  also  extensively  analyzed.  One  of  the  original  design 
premises  was  the  availability  of  an  Activity  Support  File  (ASF).  This  file  was 
not  developed  and  remains  in  a very  preliminary  state  of  specification.  For 
reasons  similar  to  those  which  have  precluded  effective  specification  of  the 
ASF  analysis  of  support  and  cost  data  led  to  little  usable  logic  within  TRAM. 
Also,  certain  cost  data  requested  from  CNET  N6  was  not  made  available  due  to 
its  apparent  sensitivity,  thus  the  support  and  cost  data  analyses  were 
incomplete. 

A major  objective  in  developing  TRAM  was  to  have  it  cycle  from  its  interactive 
interface  with  the  user  through  to  a siimmary  output  of  resources.  Preliminary 
algorithms  in  the  support  and  cost  areas  were  incorporated  to  permit  the  cycling, 
however,  it  is  expected  that  major  refinements  must  be  made  in  these  areas. 
However,  considering  the  results  of  the  field  test  to  be  discussed  in  Section 
IV  of  this  report,  it  appears  that  the  techniques  developed  and  the  balance  in 
development  emphasis  matched  many  of  the  requirements  for  planning  at  CNTECHTRA. 
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SECTION  IV 

TRAM  FIELD  TEST  AT  CNTECHTRA 


FIELD  TEST  OVERVIEW 

INTRODUCTION.  The  TRAM  system  was  subject  to  an  intensive  three-week  trial  during 
the  period  12  October  to  29  October  1976.  This  user  trial  was  conducted  at 
CNTECHTRA.  The  chief  user  of  this  model  during  this  test  was  the  Plans,  Programs 
& Facilities  Department  (N-2),  followed  by  the  Management  Department  (015),  and 
the  Resources  Management  Department  (N-5).  A short  demonstration  was  given  to  a 
Training  Program  Coordinator  (TPC)  during  this  test.  Discussions  were  held  with 
numerous  personnel  in  an  effort  to  understand  applications  of  the  model  and  to 
develop  the  logic  for  necessary  enhancements.  A demonstration  of  the  system  was 
also  given  to  CNET  at  Pensacola  on  27  October  1976  in  an  effort  to  broaden  the 
base  of  understanding  of  the  TRAM  logic  and  to  exchange  information  that  would 
be  used  in  further  development  in  the  areas  of  TRAM  technology.  During  this 
period,  the  necessary  information  was  gathered  to  (1)  estimate  the  utility  of 
the  TRAM  system,  (2)  estimate  the  cost  of  operation  of  the  TRAM  system  under  a 
variety  of  configurations,  (3)  recognize  deficiencies  in  the  TRAM  system,  and 
(4)  develop  the  recommendations  necessary  for  continued  development  of  the  TRAM 
technology. 

ENVIRONMENT.  This  test  was  physically  conducted  in  the  offices  of  N-2  at  CNTECHTRA. 
The  programs  used  in  this  test  were  located  on  two  identifications  of  the  National 
CSS  timeshare  system.  Access  to  this  system  was  via  dial-up  telephone  circuits. 
Both  local  (Memphis)  and  in-dial  WATS  lines  are  available  in  the  area.  The 
principal  terminal  used  was  the  Teletherm  1030  printing  terminal,  although  compati- 
bility was  established  with  other  30  CPS  CRT  terminals  located  at  CNTECHTRA.  No 
local  high-speed  printer  was  available  during  this  test.  The  data  base  for  this 
test  consisted  mainly  of  data  gathered  from  NITRAS,  dated  15  June  1976,  the  1000/2 
files  dated  June  1976,  and  the  Per  Capita  Cost  (PCC)  data  for  Fiscal  Year  1975. 
These  data  were  approximately  3 months  old  for  the  operational  test  (the  PCC  data 
were  "current,"  as  no  new  fiscal  year  data  were  available). 

OBJECTIVES.  The  objectives  of  this  field  test  were: 

1.  To  test  the  TRAM  system  in  an  operational  environment. 

2.  To  determine  the  applicability  of  the  TRAM  technology  to  CNTECHTRA' s 
requirements. 

3.  To  identify  major  deficiencies  in  the  TRAM  system. 

4.  To  identify  enhancements  that  would  be  desirable. 

5.  To  determine  operational  costs  for  typical  problems. 

6.  To  record  overall  system  reliability. 
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OPERATIONAL  TEST  ACTIVITIES 

The  TRAM  operational  test  was  broken  into  three  parts.  The  first  week  was  devoted 
to  demonstrating  the  system  to  Codes  N-2  (Plans,  Programs  and  Facilities),  N-5 
(Resources  Management)  and  015  (Management)  personnel  at  CNTECHTRA.  The  second 
and  third  weeks  were  spent  applying  problems  presented  by  these  personnel  to  the 
TRAM  system.  During  the  final  week,  training  was  conducted  with  N-2  personnel 
to  allow  ongoing  operation  of  the  system. 

INITIAL  DEMONSTRATIONS.  The  initial  demonstrations  were  intended  to  demonstrate 
to  non-computer  oriented  personnel  the  capabilities  of  the  TRAM  system,  the  ease 
of  operation,  and  the  potential  results  that  could  be  obtained.  During  these 
periods,  specific  questions  were  asked  so  as  to  obtain  data  necessary  for  eval- 
uation of  an  improvement  to  the  TRAM  system.  Several  recommendations  were  immedi- 
ately incorporated  into  the  system  as  a result  of  these  discussions.  These  are 
documented  later  in  this  section. 

OPERATIONAL  EXAMPLES.  Per  previous  request,  several  operational  examples  were 
submitted  for  TRAM  execution.  A summary  of  the  types  of  problems  encountered  is 
as  follows: 

1.  Problems  requiring  instructor  computations  to  allocate  instructors  to 
courses. 

2.  Decrementing  and  consolidation  of  complex  actions. 

3.  Actual  problems  requiring  an  immediate  response.  The  data  were  several 
months  old,  thus  preventing  actual  use  of  the  results  calculated  by  the 
model . 

MODEL  DEFICIENCIES/CORRECTIONS 

Model  deficiencies  noted  during  this  evaluation: 

1.  The  persons  using  the  model  were  accustomed  to  working  with  activity  names 
rather  than  UIC  codes.  The  model  obviously  must  work  with  these  codes. 
This  problem  was  alleviated  in  two  ways.  First,  a listing  of  all  activ- 
ities, their  codes,  and  a summary  of  authorized  billets,  was  included  as 
an  appendix  to  Technical  Memorandum  76-3.  Second,  program  TST  and 
executive  LOOK  were  written  to  permit  the  user  to  look  up  any  course  in 
NITRAS  to  ascertain  l/IC  codes. 

2.  There  was  an  identified  requirement  for  more  detail.  This  was  exemplified 
by  the  request  for  a listing  of  instructor  requirements  by  course  for  all 
courses  involved  in  an  action.  Program  LISTIC  and  executive  ICOMPIO  were 
written  to  provide  this  instructor  summary  by  CDP. 

A need  existed  for  more  detailed  output  from  subroutine  COST.  This  in- 
creased output  could  not  be  accommodated  during  the  evaluation  period. 

3.  The  program  encountered  problems  when  consolidations  were  attempted  at 
activities  where  the  same  CIN  was  taught  under  multiple  CDP's.  The  most 
prominent  examples  of  these  are  BE&E  and  AFUN  courses.  The  consolidation 
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logic  was  changed  to  minimize  the  impact  of  this.  However,  an  across- 
the-board  fix  Could  not  be  made  as  the  courses  have  many  conmon  modules 
and  resources.  This  problem  will  exist  until  a better  way  is  devised 
to  load  these  courses  in  NITRAS. 

4.  Problems  were  encountered  using  the  system  default  for  planned  input 
data.  In  several  cases,  the  AOB  and  hence  the  instructor  requirements 
generated  by  the  model  were  quite  high  due  to  the  absence  of  planned 
input  and  the  default  value  was  too  high.  The  system  default  was  removed 
and  the  problem  became  worse  in  the  opposite  direction.  Further  analysis 
proved  the  missing  loads  were  generally  related  to  self-paced  courses. 

The  default  logic  was  again  reprogrammed,  and  the  values  now  appear 
reasonable. 

5.  Several  other  minor  problems  were  corrected  during  the  user  evaluation. 
SYSTEM  PROBLEMS  ‘ 

Twice  during  the  evaluation  period  the  timeshare  vendor's  system  was  unavailable 
for  significant  periods.  The  first  period  of  downtime  was  on  the  first  day  of 
demonstrations,  causing  an  impact  to  the  initial  "kick  off"  meeting.  The  second 
period  of  downtime  was,  on  the  last  full  day  of  the  evaluation,  impacting  the 
training  of  follow-on  users.  Periods  of  downtime  as  significant  as  these  have  not 
been  previously  experienced,  and  it  is  doubtful  that  they  should  continue. 

The  telephone  system  also  caused  minor  problems.  The  local  Memphis  telephone 
number,  as  provided  by  the  timeshare  vendor,  consistently  proved  too  noisy  and  at 
too  low  an  amplitude  for  reliable  terminal  operation.  However,  the  dial-WATS 
lines  to  the  multiplexer  in  Atlanta  had  none  of  these  problems,  so  operation 
was  not  affected.  ^ , 

Other  minor  equipment  problems  encountered  during  this  test  were  due  to  blown 
fuses  on  the  portable  terminal. 

CONCLUSIONS  AND  RECOMMENDATIONS 

Based  upon  experience  gained  and  discussions  held  during  the  test  period,  the 
following  conclusions  and  recommendations  are  made. 

CONCLUSIONS 

Operational  Test  Results.  The  model  was  tested  in  approximately  20  significant 
configurations  during  this  user  test,  with  many  variations  to  these  basic  runs. 

The  following  surtmarize  the  results  of  running  these  problems.  These  conclusions 
are  based  on  analysis  of  the  34  decrements  proposed  by  CNTECHTRA  as  a preliminary 
test  to  measure  the  applicability  of  TRAM  to  this  type  of  exercise. 

1.  The  TRAM  model,  as  presently  configured,  does  have  applicability  in 
the  CNTECHTRA  organization. 
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P.  Tho  iiiobt  useful  feature  in  the  I RAM  model  is  the  ability  to  quite 
accurately  calculate  instructor  requirements  based  on  "raw"  data 
in  NITRAS. 

3.  The  default  concept,  where  course  data  gathered  from  an  extensive 
parametric  analysis  are  used  to  substitute  for  invalid  or  sketchy 
NITRAS  data,  was  established  as  a viable  operational  tool  without 
which  these  instructor  computations  would  not  be  possible. 

4.  The  alternate  (or  distributed)  data  base  concept,  where  a portion  of 
the  NITRAS  data  is  duplicated  and  online  on  a second  computer,  is 
justified  and  cost  effective. 

5.  The  1000/2  file  by  its  very  nature  must  be  the  "master"  file  controlling 
the  model  determination  of  what  constitutes  an  activity.  All  other 
files  must  be  slaved  to  this  file.  Where  other  files  cannot  be  slaved 
to  the  1000/2  file  (such  as  the  Per  Capita  Cost  file),  the  deviations 
must  be  handled  as  exceptions. 

6.  The  most  useful  operating  mode  for  TRAM  is  consolidation  option.  This 

is  due  to  (1)  there  is  a substantial  reduction  in  the  manual  labor  required 
to  evaluate  a consolidation,  and  (2)  there  is  a great  deal  more  multiple 
siting  of  courses  than  was  thought  to  be  the  case  by  CNTECHTRA  personnel. 

7.  The  weakest  area  in  the  TRAM  model  is  the  logic  used  to  calculate  support 

and  command/ staff  overhead  personnel  required  at  an  activity. 

8.  The  costing,  or  economic  analysis,  provided  by  TRAM  is  somewhat  inadequate 
due  to  the  gross  approximation  techniques  used  in  developing  the  overall 
personnel  affected  in  a decrement  action. 

9.  The  major  application  of  the  TRAM  model  was  to  evaluate  decrement  actions 

and  consolidations;  the  only  increments  were  additional  loads  placed  in 

existing  courses. 

Data  Requirements.  The  data  requirements  applicable  to  the  TRAM  model  can  be  di- 
vided into  four  basic  categories.  These  categories  are  as  follows; 

Congressional  Reporting  Systems.  These  data  are  the  data  required  for  the  Military 
Manpower  Training  Report  (MMTR)  and  for  various  phases  of  the  budget  cycle.  These 
requirements  were  studied  in  some  detail  when  drawing  up  the  specification  for  the 
TRAM  model.  Essentially,  the  source  data  for  these  reports  are  in  NITRAS.  However, 
the  NITRAS  MCRF  data  in  many  cases  are  merely  playing  back  to  these  people  data 
they  loaded  or  controlled  in  the  first  place.  These  data  are  marked  by  two  common 
attributes.  First,  the  accuracy  must  be  carried  down  to  the  last  "nut  and  bolt." 

It  is  important  in  the  MMTR  whether  21  or  23  foreign  students  plan  to  take  a course. 
Likewise,  it  is  important  whether  pipeline  delays  affect  DSN  or  USNR  personnel. 
Second,  a complete  trackability,  or  audit,  trail  is  required.  It  is  important  to 
know,  or  be  able  to  recover,  what  figure  was  reported  three  or  six  months  ago  and 
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have  a record  of  why  it  differs  in  the  latest  submission.  These  data  requirements 
do  not  lend  themselves  to  aggregate  flow  models  with  default  characteristics 
such  as  TRAM.  These  data  requirements  are  best  filled  by  a system  such  as  NITRAS. 

In  fact,  in  the  future  these  requirements  may  become  very  specialized  in  NITRAS. 

Also,  some  potential  model  applications  can  be  handled  by  summation  reports 
due  to  large  amounts  of  data  carried  to  meet  Congressional  reporting  requirements. 

Billet  Data.  Billet  data  at  first  were  thought  to  have  the  same  exacting  re- 
quirement as  ..the  above  data.  It  is  important  for  the  programming  branch  (CNTECHTRA 
N22)  to  know  every  billet  of  every  type  they  are  authorized  by  location.  There 
is  a continual  flow  of  data  from  the  activities  to  CNTECHTRA,  usually  through  the 
1000/2  files.  Billets  are  carried  to  exacting  levels,  and  are  organized  basically 
by  courses  taught.  On  the  surface,  there  appears  little  utility  in  using  TRAM  in 
assisting  this  process. 

However,  two  major  and  somewhat  interrelated  problems  have  potential  for  TRAM 
utility.  The  first  problem  is  that  all  updates  by  the  activity  to  the  1000/2 
files  are  not  made  simultaneously  and  that  there  may  be  considerable  delay  in 
getting  the  updates  made  (on  the  order  of  several  months).  Once  these  updates 
are  made  there  is  no  certainty  that  the  1000/2  reports  will  be  printed  and  mailed 
to  CNTECHTRA.  The  second  problem  is  that  the  billets  cannot  always  be  tied  to 
a course.  For  example,  at  Fleet  ASW  Training  Center,  San  Diego,  nearly  one-third 
of  all  courses  taught  were  of  sufficiently  small  capacity,  or  were  taught  at  such 
low  convening  frequency,  that  no  instructors  were  justified  directly  by  those  courses. 
Ihis  factor,  coupled  with  the  timeliness  of  updating  of  the  1000/2  files,  makes 
ascertainment  of  billet  assignment  by  CNTECHTRA  personnel  difficult.  This  fact 
was  highlighted  through  a CNET  request  made  during  the  evaluation  period  for 
instructor  authorized  billets,  by  course.  This  information  was  not  readily 
available  at  CNTECHTRA,  and  was  complicated  by  the  fact  that  all  1000/2's  were 
not  and  could  not  be  arranged  to  facilitate  this  kind  of  request.  This  problem 
was  entered  and  run  using  the  TRAM  model,  with  an  answer  obtained  immediately. 

The  TRAM  results  were  not  passed  on  to  CNET  as  the  data  base  was  three  months  old 
and  not  enough  operating  experience  had  been  obtained  with  the  model.  An  after- 
the-fact  analysis  established  that  the  model  results  were  valid.  This  indicates 
that  the  model  has  applicability  in  the  area  of  tying  authorized  instructor  billets 
to  actual  courses  taught. 

Reprogramming.  This  is  the  area  discussed  previously  where  current  assets 
(basically  instructors)  are  reassigned  to  meet  new  or  expanding  requirements. 

The  TRAM  model  was  designed  especially  to  fulfill  these  requirements. 

Long-Range  (Facility)  Planning.  This  involves  out-year  planning  where  the  common 
denominator  is  dollars.  All  resource  requirements  are  converted  to  this  common 
denominator  and  the  comparative  analysis  is  made.  This  process,  however,  is 
probably  the  least  straightforward  one  studied.  Any  process  that  is  not  straight- 
forward, or  does  not  consistently  follow  the  same  logical  pattern,  is  very 
difficult  to  model.  Difficulty  had  been  anticipated  in  developing  models  for 
this  area  of  CNTECHTRA' s operation,  and  the  inability  of  TRAM  to  respond  to  these 
types  of  problems  manifested  itself  throughout  the  model  test. 
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RECOMMENDATIONS.  The  recommendations  formulated  during  this  user  evaluation  fall 
into  two  categories:  those  required  to  correct  recognized  deficiencies,  and 
those  that  would  project  the  TRAM  technology  into  useful  long-term  applications. 

The  following  deficiencies,  and  recommendations  for  overcoming  these  deficiencies, 

' were  formulated  during  the  evaluation  period. 

Data  Base  Update.  Portions  of  the  TRAM  Icg'c  proved  adequate  for  providing 
immediate  support  to  CNTECHTRA  N-2  without  any  modification.  The  utility  of 
the  TRAM  model  was  limited,  however,  by  the  fact  that  the  NITRAS  data  base  was 
current  for  June  1976,  while  the  test  was  conducted  in  October  1976.  Therefore, 

^ many  of  the  problems  run  were  useful  for  evaluation  purposes,  but  could  not  be 

used  in  an  operational  environment.  For  example,  SSC  at  Orlando  is  just  beginning 
to  get  up  to  capacity  and  become  operational  for  the  Basic  Electricity  and 
* Electronics  group  of  courses.  The  current  NITRAS  shows  this,  yet  the  NITRAS 

tape  contained  only  a skeleton  of  this  buildup;  therefore,  this  training  center, 
which  was  of  high  interest  to  CNTECHTRA  personnel,  could  not  be  adequately  analyzed. 
It  is  recommended  that  (1)  a current  NITRAS  file  be  generated,  and  (2)  procedures 
be  established  to  allow  a regular  update  of  this  file  (by  complete  replacement)  so 
' that  valid  operational  use  of  this  system  is  available. 

The  procedures  to  accomplish  this  have  been  discussed  with  015  (Management) 
personnel  at  CNTECHTRA  and  N-73  (Management  Information)  personnel  at  CNET. 

; Correct  1000/2  Analysis  Program.  It  was  noted  during  an  analysis  of  the  School 

of  Diving  and  Salvage  that  there  was  a discrepancy  between  the  calculated  instructor 
requirements  (31)  and  the  requirements  as  generated  by  the  1000/2  analysis  program 
(8).  The  31  figure,  as  developed  through  the  model  logic,  proved  to  be  correct. 

An  analysis  showed  that  the  logic  used  to  analyze  the  enlisted  1000/2  file  needs 
to  be  refined.  Basically,  the  logic  used  to  analyze  the  officer  1000/2  file 
should  be  transferred  and  used  on  the  enlisted  file  also.  This  entails  reading 
I the  text  of  the  billet  sequence  code  title  field,  looking  for  keywords  such  as 

INST,  INSTR,  etc.,  while  selecting  non-instructor  variables  to  be  omitted.  The 
immediate  correction  for  this  problem  was  to  update  the  file  (UIC  matrix)  manually. 

Improved  Consolidation  Logic.  Currently,  the  model  allows  an  activity  (or  portion) 
to  be  closed  with  the  load  transferred  to  up  to  13  preassigned  activities.  This 
logic  should  be  expanded  to  allow  (1)  automatic  single  siting  of  courses,  and  (2) 
transfer  of  load  from  one  location  to  any  other  location  without  the  need  for 
indicating  the  receiving  activities.  This  will  require  the  accumulation  of 
‘ courses  and  projected  load  in  a dummy  file  for  those  courses  not  taunht  elsewhere. 

Conmand,  Staff,  and  Support  Requirements.  The  logic  to  determine  command,  staff, 
and  support  billets/ceiling  points  is  inadequate  for  any  detailed  analysis  of 
these  requirements.  During  the  model  development  the  1000/2  files.  Per  Capita 
Cost  System,  OPNAV  5320  Manpower  Listings,  and  Host/Tenant  Support  Agreements, 
were  all  intensively  studied  with  the  intent  of  improving  this  logic.  Unfortunately, 
. such  improvement  proved  elusive.  Many  of  the  support  functions  provided  by  CNET 

activities  are  not  defined  in  any  of  the  aforementioned  files,  especially  if  this 
support  is  to  another  CNET  activity.  Many  other  relationships,  such  as  between 
RTC's,  SSC's,  NTC's  and  their  respective  ADCOM's  are  not  spelled  out  in  enough 
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detail  to  provide  any  improvement  to  the  existing  model  logic.  TRAM  will  only 
be  accurate  for  direct  training  requirements  until  these  relationships  become 
further  defined. 

Cost  Analysis.  The  TRAM  model  only  provides  cost  data  for  aggregate  military 
and  civilian  personnel.  Military  personnel  should  be  broken  down  into  officer 
and  enlisted  categories. 

Increased  Detail  Reports.  A factor  which  became  apparent  during  the  operational 
test  is  that  CNTECHTRA  needs  detailed  intermediate  data  as  well  as  the  summary 
results.  For  example,  they  cannot  accept  a summary  total  of  these  savings  at  an 
activity  without  the  detail  of  all  factors  included  in  those  savings.  Two  programs 
were  written  during  the  evaluation  to  improve  this  deficiency.  This  capability 
should  be  expanded. 

RECOMMENDED  FUTURE  TRAM  APPLICATIONS.  The  previous  section  discussed  the  appli- 
cation of  TRAM  to  current  operational  problems.  These  applications  of  TRAM  are 
quite  easy  to  visualize  as  the  problems  are  real,  immediate,  and  visible.  The 
application  of  TRAM  to  more  theoretical  problems  is  somewhat  harder  to  visualize. 
The  potential  for  application  of  the  TRAM  technology  is  perhaps  greater  with  a 
much  increased  base  for  savings,  and  hence  payback,  than  has  been  encountered  in 
the  immediate  operational  arena.  Some  potential  applications  are  delineated  below 
whereby  future  development  might  encompass  these  areas. 

Instructor  Optimization.  Instructor  billets  are  currently  authorized  based 
mainly  on  instructor  computation  formulas  developed  by  CNTECHTRA.  These  authorized 
billets  are  subject  to  periodic  audit.  However,  there  is  not  a systematic  analysis 
made  to  optimize  the  requirements  for  these  billets.  The  TRAM  model  could  do 
this  using  the  following  steps. 

1.  Determine  the  instructor  requirement  for  handling  current  input  at 
current  convening  frequency. 

2.  Recompute  this  requirement  at  the  most  optimum  convening  frequency. 

3.  If  the  results  differ,  evaluate  any  savings,  based  on  instructor 
requirement  reduction  versus  increased  student  pipeline  costs. 

This  would  require  modification  to  program  ICALC  to  recognize  optimum  convening 
frequencies  (and  perhaps  second  or  third  sub-optimization  points).  A change  in 
logic  would  have  to  be  made  to  recognize  those  courses  involved  in  pipeline 
type  instructional  flows.  This  type  of  optimization  could  lead  to  a more  thorough 
course  by  course  analysis  than  the  aggregate  flows  permit. 

A second  possibility  exists  for  more  effective  instructor  utilization.  During  the 
field  test,  most  consolidations  submitted  for  evaluation  consisted  of  actions 
where  one  training  center  (X)  would  be  shut  down  and  the  load  transferred  to 
another  center  (Y).  This  resulted  in  calculated  savings  at  the  command,  staff, 
and  support  levels  due  to  the  economies  of  scale  garnered  by  this  consolidation. 
Instructor  savings  were  not  realized  in  a consolidation  since  the  courses  taught 
at  (X)  are  not  taught  at  (Y),  hence  they  are  transferred  intact.  No  prohlem  was 
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presented  whore  the  consolidation  was  to  he  evaluated  on  a course  l)y  course 
basis  in  an  effort  to  improve  instructor  utilization.  Yet,  during  some  example 
consolidation  problems  it  was  found  that  a proliferation  of  courses  exists 
among  some  activities. 

Training  System  Analysis.  NITRAS  holds  the  promise  that  utilization  of  the  vast 
amounts  of  data  stored  in  its  system  will  lead  to  a greater  awareness  of  the 
problems  of  inefficiency  in  the  training  command,  and  would  provide  the  visibility 
to  correct  those  problems.  However,  the  very  mass  of  data  involved,  higher 
priority  requests  for  limited  report  generation  time,  and  certain  data  integrity 
problans,  all  have  combined  to  keep  this  potential  from  being  realized.  To  date 
TRAM  offers  a potential  for  providing  this  much  needed  use  of  NITRAS  data. 

Typical  of  the  "what  if's"  that  would  prove  desirable  to  evaluate  are; 

1.  What  is  the  priority  of  courses  where  requirements  are  greater  than 
the  capacities? 

2.  How  many  instructors  can  be  freed  up  by  transferring  portions  of  a 
course  to  on-the-job  training? 

3.  What  trade-offs  within  resources  would  meet  the  greatest  number  of 
prioritized  requirements? 

4.  What  activity  closing  order  would  be  indicated  by  the  course  training 
priorities? 

5.  What  savings  really  would  accrue  with  a more  level  loading  (eliminating 
cyclic  fluctuations)? 

6.  What  is  the  cost  and  permissible  backlog  size  required  to  ensure  level 
loading? 

This  summarizes  just  a few  of  the  potential  applications  where  the  TRAM  technology, 
in  concert  with  the  NITRAS  data  base,  could  provide  assistance  in  obtaining  the 
in-depth  understanding  of  complex  interactions,  so  as  to  effectively  make  the 
tradeoffs  necessary  to  maximize  instruction  while  minimizing  resource  requirements. 

OPERATING  COSTS 

The  timeshare  vendor's  charges  can  be  broken  into  three  parts; 

1.  Online  storage 

2.  Model  operation 

3.  Oata  base  maintenance 

ONLINE  STORAGE.  The  TRAM  system  currently  requires  25  cylinders  {120K  bytes/cyl inder ) 
of  permanent  storage.  Nearly  half  of  this  storage  is  required  for  the  NITRAS 
summary  file.  The  current  charges  of  this  storage  are  $510  per  month,  or  about 
$17  per  day.  During  the  evaluation  period  this  storage  was  kept  continually  online. 
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However,  to  minimize  storage  costs,  the  system  can  be  stored  on  magnetic  tape 
and  only  brought  online  as  required.  The  cost  to  read  all  files  to  tape  is 
about  $15.  Thus,  if  the  system  is  brought  up  once  per  week,  the  costs  should 
be  less  than  $140  per  month. 

MODEL  OPERATION.  Two  types  of  charges  are  incurred  during  operation  of  the  TRAM 
model.  The  first  is  an  hourly  charge  of  $14  per  connect  hour.  The  second  charge 
is  a processing  charge.  This  processing  charge  is  made  up  of  two  components,  a 
VPU,  Variable  Processor  Unit,  charge  and  an  I/O  charge.  A VPU  is  determined  by 
CSS  procedures,  and  is  charged  at  a rate  of  20<t  per  VPU.  I/O  charges  are  billed 
at  13(t  per  hundred  I/O's.  One  I/O  constitutes  an  800  Byte  string  of  data.  A 
sample  of  approximate  charges  incurred  in  a model  run  are  as  follows: 


Base 

Variable  $ 

Total  $ 

Typical  $ 

] 

Program 

Cost 

/lOO  Courses 

/lOO  Courses 

/36  Courses 

1 

i 

PARAM 

,87 

NA 

.87 

.87 

i 

TRAM 

.87 

.51 

1.38 

1 .01 

■j 

I CALC 

.87 

.52 

1 .39 

1 .06 

ICSORT 

1.08 

1.16 

2.24 

1.48 

1 

I FACE/ 

j 

COST 

3.84 

.75 

4.59 

4.09 

1 

DISP 

.38 

NA 

.38 

.38 

$7.91 

$2.94 

$10.85 

$8.89 

This  chart  should  allow  a user  to  estimate  quite  closely  the  charges  for  a model 
run.  These  charges  are  in  addition  to  the  hourly  charge  ($14/hr.). 


When  using  this  table,  the  following  course  counts  can  be  estimated  for  each  type 
of  action;  i.e.,  decrements,  increments,  and  consolidations.  Each  course  on  a 
decrement  is  counted  only  once;  therefore,  if  there  are  36  courses  at  an  activity 
which  is  decremented,  the  run  cost  would  be  about  $8.89.  Using  the  increment 
option,  a course  action  must  be  counted  twice  - once  as  a decrement  from  its 
current  configuration  - once  as  an  increment  with  its  new  configuration.  Therefore, 
50  courses  being  incremented  would  cost  about  $10.85  based  on  the  Total  $/100 
Courses  column  of  the  table.  For  consoldiations,  courses  are  counted  once  for 
the  decrement  action,  and  then  twice  more  at  each  "TRANSFER  TO"  activity  which 
presently  teaches  the  course.  However,  if  it  is  established  as  a new  course  at 
the  "TRANSFER  TO"  activity,  it  is  only  counted  once  for  the  increment  portion  of 
the  action. 

DATA  BASE  MAINTENANCE.  There  are  no  established  procedures  for  data  base  mainte- 
nance and,  hence,  a detailed  analysis  cannot  be  made. 


However,  it  can  be  estimated  that  two  hours  of  online  time  will  be  required  to 
replace  a current  data  base  with  a new  one.  Past  history  has  shown  that  processing 
charges  (including  connect  time)  will  average  $80  per  hour,  or  about  $160  total 
to  replace  the  data  base. 
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SECTION  V 

SCRR  AND  TPF  UTILITY  ASSESSMENT  AT  TRAPAC 
FINAL  STUDY  RESULTS 


INTRODUCTION 

Four  major  tasks  were  performed  during  Phase  IV  to  accomplish  the  utility  assess- 
ment of  the  SCRR  and  TPF  models.  The  tasks  and  their  performance  periods  are 
shown  below: 


TRAPAC  FIELD  TEST 

MODIFY  SOFTWARE  TO  INCOR- 
PORATE ENHANCEMENTS 


3 Jan  - 5 Mar  76 
8 Mar  - 9 Jul  76 


TRAIN  TRAPAC  PERSONNEL, 
INSTALL  SYSTEM 

SYSTEM  DOCUMENTATION 


12  Jul  - 20  Aug  76 
23  Aug  - 17  Sept  76 


These  tasks  were  defined  as  a direct  result  of  the  DOTS  Test  and  Evaluation  per- 
formed in  June  1975  by  the  Navy  Personnel  Research  and  Development  Center.  The 
T&E  report  published  in  September  1975  recommended  that  the  DOTS  models  be  in- 
stalled and  subjected  to  an  extended  evaluation  at  a functional  level  command. 

TRAPAC  FIELD  TEST 


The  purpose  of  the  field  test  was  to  demonstrate  the  degree  of  utility  that  the 
two  previously  developed  models  (SCRR  and  TPF)  and  associated  data  base  would  have 
for  the  Navy  training  managers  at  the  activity  and  functional  command  level. 

Five  major  definable  tasks  were  performed  in  order  to  complete  the  field  test. 
Briefly,  they  can  be  described  as  follows;  greater  detail  is  provided  in  TAEG 
Report  No.  33  - DOTS  Utility  Assessment: 

0 Install  Software  at  TRAPAC 

The  TPF  and  SCRR  models  and  support  programs  were  reinstalled  in 
the  IBM  CKF  workspace  at  National  CSS.  Some  minor  modifications 
were  made  at  that  time.  The  data  base  format  was  defined  and 
data  were  collected  from  five  TRAPAC  activities.  A period  of 
data  base  purification  followed  the  initial  TRAPAC  data  load 
operation.  Approximately  five  thousand  records  (punched  cards) 
were  inputted  to  establish  the  data  base. 
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0 Identify  and  Document  Model/Data  Base  Applications 

The  five  TRAPAC  activities  involved  in  the  field  test  were  briefed 
on  the  purpose  and  schedule  for  this  particular  task  as  well  as  the 
following  three  tasks,  which  culminated  in  a review  of  the  field 
test  results  by  the  evaluation  team.  The  objective  was  to  identify 
situations  arising  during  the  normal  course  of  managing  training 
to  which  the  models  might  potentially  apply.  Department/division 
heads  and  staff  personnel  were  interviewed  in  order  to  identify 
these  situations.  The  result  was  a list  of  potential  applications. 

0 Utilize  Model  Software  and  TRAPAC  to  Solve  Identified  Problems 

Several  of  the  potential  model  applications  were  analyzed  to  a 
greater  depth.  Changes  or  inputs  to  correspond  with  the  approach 
taken  by  training  managers  in  resolving  a particular  problem 
situation  were  prepared.  The  appropriate  model  was  run  and  results 
were  compared  with  those  expected  by  the  training  managers.  Only 
a few  tests  of  this  type  could  be  made  because  of  time  constraints 
and  data  inconsistencies. 

0 Define  Usability  Enhancements 

During  the  briefings  and  subsequent  interviews,  TRAPAC  activity 
personnel  identified  a number  of  changes  or  additions  which  they 
believed  would  make  the  models  more  suitable  to  their  use.  These 
ranged  from  minor  data  base  modifications  to  new  additional  modeling 
tasks.  A list  of  proposed  enhancements  was  maintained  for  later 
analysis,  prioritization,  and  possible  development. 

0 Review  by  Evaluation  Team 

A questionnaire  (see  TAEG  Report  No.  33)  was  developed  for  TRAPAC 
personnel  to  determine  the  frequency  and  associated  workload  on 
identified  applications.  The  results  were  tabulated  and  presented 
to  key  personnel  at  each  activity.  Activities  were  requested  by 
TRAPAC  to  develop  a position  statement  regarding  the  usefulness 
of  DOTS  models  to  the  management  of  training  within  their  function. 
TRAPAC,  Activity,  and  TAEG  personnel  (IBM  representatives  were  not 
present)  reviewed  the  overall  field  test  results  to  decide  the 
future  course  of  the  DOTS  effort  at  TRAPAC.  A decision  was  made  to 
incorporate  certain  enhancements  whereby  the  transition  can  be  made 
from  RJ^n  to  the  Dperational  Phase  when  resources  become  available. 

MODIFY  DOTS  SOFTWARE  TO  INCORPORATE  ENHANCEMENTS 

Three  major  enhancements  were  incorporated  into  the  DOTS  models/data  base  software 
based  upon  the  COMTRAPAC  field  test  analysis.  They  include:  (1)  instructor  billet 
computation,  (2)  a number  of  data  base  modifications  which  include  capability  to 
store  a number  of  direct  teaching  and  support  time  categories  by  instructor,  and 
(3)  a data  base  maintenance  system.  The  changes  which  were  developed  are  shown 
below: 
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Instructor  Billet  Computation 

A program  was  developed  (in  RAMIS)  to  calculate  required  instructor 
billets  based  upon  Demand  and  Student/Instructor  Ratios  by  CDP. 

The  program,  named  "ICOMP,"  is  described  in  Section  IV  of  TAEG 
Report  No.  36  - TRAPAC  User's  Manual. 

Data  Base  Enhancements 

1.  General  data  base  format  changes. 

0 Three  fields  for  NEC/NOBC  were  added  to  the  instructor 
file,  e.g.,  NEC3,  NEC4,  NEC5. 

0 Three  optional  fields  of  A6  format  were  added  to  the 
course  file,  e.g.,  OPTl , 0PT2,  0PT3. 

0 Three  fields  for  equipment,  space,  and  instructor  capaci- 
ties were  added  to  the  course  file,  e.g.,  ECAP,  SCAP,  PCAP. 

0 Names  of  existing  JNO  and  PAOB  fields  were  changed  to 
MAXCAP  and  MINCAP  respectively  in  course  file. 

0 A field  for  Planned  AOB  (PAOB)  was  incorporated  into  the 
course  file. 

2.  The  following  activity  profile  data  fields  were  added  to  the 
instructor  file: 

- Hours  in  contact  with  student 

- Curriculum  Development/Task  Analysis 

- Equipment/Training  and  Maintenance 

- Preparation  for  Instruction  and  Related  Duties 

- In-service  Instructor  Training  ("Break-in"  time) 

- Cross-training  done  to  take  advantage  of  low  student  enrollment 
(not  an  absolute  requirement) 

- Factory  Training/Workshops,  etc. 

- Military  Duties/Physical  Training/Other 

- Formal  Instructor/Supervisor  School 

- Fleet  Assistance  (non-course  related) 

- Supervision/Administration 

- Annual  Leave 


P 


TAEG  REPORT  NO.  V 


- Sick  Leave 

- Special  Liberty 
C.  Data  Base  Maintenance 

A data  base  maintenance  system  was  designed  consistent  with  a TRAPAC 
planned  future  system  for  maintaining  NITRAS.  The  system  incorporates: 

0 Activity  level  prompting  programs  on  WANG  and  storage  of 
changes  on  a tape  cassette. 

o Functional  level  data  base  management  expertise  (Data  Base 
Manager)  to  list  and  review  tapes  and  transmit  them  to  NCSS 
on  a periodic  (weekly)  basis. 

0 NCSS  level  programs  to  process  changes,  trap  and  print  change 
errors,  and  prepare  data  base  listings  for  functional  and 
activity  distribution. 

TRAPAC  PERSONNEL  TRAINING/SYSTEM  INSTALLATION 

The  primary  objective  of  this  task  was  to  train  TRAPAC  personnel  to  operate  the 
DOTS  data  base,  SCRR  and  TPF  model  software.  The  training  was  accomplished  over 
a live-week  time  period  through  hands-on  operation  of  the  DOTS  software.  At  the 
conclusion  of  the  training  period  COMTRAPAC  and  the  training  activities  will  per- 
form an  extended  evaluation  of  the  DOTS  data  base  and  models. 

A secondary  objective  was  to  use  the  maintenance  system  software  to  bring  the 
DOTS  data  files  up-to-date  and  to  determine  the  cost  required  to  maintain  the 
DOTS  data  base  in  terms  of  manpower  and  NCSS  computer  costs. 

Meetings  were  held  with  key  personnel  at  each  of  the  training  activities  to  initi- 
ate the  data  base  update  task.  A preliminary  DOTS  data  base  maintenance  adminis- 
trative system  was  developed.  Software  modifications  required  to  install  the 
WANG  software  on  the  TRAPAC  hardware  were  implemented.  Initial  training  for  the 
Data  Base  Manager  (DBM),  including  an  introduction  to  NCSS  and  RAMIS  conventions, 
was  started  while  maintenance  data  were  being  collected  by  the  training  activities. 
Personnel  at  each  of  the  activities  were  then  trained  to  record  maintenance  data 
on  a tape  cassette  using  the  WANG  interactive  prompting  program.  Tape  cassettes 
containing  maintenance  data  were  sent  to  the  DBM  as  they  were  completed.  The  DBM 
was  then  trained  to  process  the  maintenance  transactions  into  the  DOTS  data  base 
using  NCSS/RAMIS  procedures.  The  TRAPAC  training  schedule  and  a summary  of  the 
training  tasks/topics  is  shown  in  Figure  V-1 . 

COLLECT  MAINTENANCE  DATA.  A DOTS  data  base  was  established  for  all  TRAPAC 
activities  in  January  1976.  (See  TAEG  Report  No.  33  - DOTS  Utility  Assessment.) 
Since  the  data  base  had  not  been  updated  for  a six-month  period,  the  number  of 
changes  required  to  bring  the  data  base  up-to-date  will  provide  a basis  for  pro- 
jecting weekly  maintenance  activity.  Also,  inputting  and  processing  twenty-six 
weeks  of  data  base  changes  provide  an  opportutiity  to  engage  in  extensive  on-the- 
job  training  for  both  activity  personnel  and  the  DBM. 
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Meetings  were  held  with  key  personnel  from  each  of  the  TkAPAC  activities  from 
15  July  through  21  July.  (See  Figure  V-1  . ) 


All  activity  personnel  attending  these  meetings  were  involved  in  the  January 
data  collection  and  subsequent  utility  assessment.  The  object  of  the  meetings  was 
to  describe  data  base  and  model  enhancements  incorporated  as  a result  of  the 
utility  assessment,  to  distribute  listings  of  the  three  (Course,  Facility,  and 
Instructor)  data  base  files,  and  to  discuss  the  data  base  update  and  the  mainte- 
nance training  schedule. 

Data  changes  occurring  since  January  were  noted  by  redlining  the  data  base  listing. 
Blank  forms  to  collect  data  for  new  instructors  and  courses  were  provided.  The 
major  portion  of  the  data  collection  effort  was  required  to  establish  instructor 
activity  profile  data.  The  activity  profile  is  an  estimate  of  the  number  of  hours 
expended  on  an  annual  basis  on  each  of  fourteen  activity  categories.  Time  to 
collect  these  data  ranged  from  fifteen  (15)  minutes  per  instructor  at  one  activity 
to  ninety  (90)  minutes  per  instructor  for  one  department  at  another  activity.  The 
effort  required  to  collect  activity  profile  data  is  not  repetitive.  The  initial 
activity  profile  data  must  be  collected  only  once  for  each  instructor.  The  effort 
required  to  collect  and  record  course  and  facility  data  changes  ranged  from  75  to 
100  changes  per  hour. 


TRAIN  ACTIVITY  PERSONNEL.  After  the  maintenance  data  were  collected  and  recorded 
on  the  data  base  listings,  personnel  at  each  of  the  activities  were  trained  to 
operate  the  WANG  data  base  maintenance  prompting  program.  The  prompting  program 
requests  the  user  to  enter  required  data  and  then  records  the  data  on  a WANG 
tape  cassette.  Training  time  ranged  from  one  to  three  hours  per  person.  The 
rank  of  personnel  trained  to  input  maintenance  data  ranged  from  enlisted  E-1 
to  Commander.  Prior  ADP  background  ranged  from  none  to  several  years  of  pro- 
gramming experience.  Operation  of  the  WANG  prompting  program  required  very  little 
explanation.  The  major  portion  of  the  training  time  was  devoted  to  an  explana- 
tion of  the  data  base  structure  and  the  twenty  types  of  maintenance  transactions. 
All  trainees  became  proficient  in  entering  maintenance  transactions  after  a single 
training  session,  plus  one  to  two  hours  of  hands-on  experience  entering  data 
changes  on  the  WANG  computer  terminal. 

Approximately  13,000  data  changes  were  entered  by  activity  personnel  during  the 
second  and  third  weeks  of  the  training  program.  The  time  spent  on  the  WANG 
terminal  to  enter  the  maintenance  transactions  ranged  from  125  to  200  transactions 
per  hour. 

TRAIN  DATA  BASE  MANAGER.  After  all  maintenance  transactions  were  entered  on  the 
tape  cassette,  the  cassette  was  delivered  to  the  DBM  at  COMTPAPAC.  The  remainder 
of  the  data  base  maintenance  task  is  then  performed  by  the  DBM.  The  DBM  must: 

1.  List  and  review  maintenance  transaction  tape  cassette. 

2.  Transmit  data  on  tape  cassette  to  NCSS  disk. 

3.  Process  maintenance  transactions  using  NCSS/RAMIS  procedures. 

4.  Resolve  and  correct  any  maintenance  data  errors  identified  by  RAMIS. 

5.  Generate  and  distribute  new  data  base  listings. 
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Approximately  four  weeks  were  devoted  to  DBM  training.  The  following  material 
was  covered  during  the  training  program: 

1.  TAEG  Report  No.  36  - DOTS  TRAPAC  User's  Manual 

2.  VP/CSS  Reference  Manual  (NCSS  Form  106) 

3.  VP/CSS  Edit  Command  (NCSS  Form  108) 

4.  VP/CSS  Executive  Language  (NCSS  Form  109) 

b.  RAMIS  User's  Guide  (Parts  1,  2 and  3) 

In  addition  to  the  theoretical  background  achieved  through  review  of  the  above 
documents,  twenty-six  weeks  of  data  base  changes  (approximately  13,000  changes) 
were  processed  and  entered  into  the  three  RAMIS  data  files  during  the  third  and 
fourth  weeks  of  the  training  program. 

NOTE  ON  NCSS-WANG  INTERFACE  SOFTWARE.  All  NCSS-WANG  interface  is  controlled 
by  the  program  "TC-NCSS."  "TC-NCSS"  was  written  in  BASIC  using  statements  from 
the  General  I/O  Instruction  Set  by  WANG  Laboratories  in  Tewksbury,  Massachusetts. 
The  only  unresolved  technical  problem  encountered  during  the  installation  and  use 
of  DOTS  software  involved  the  use  of  "TC-NCSS"  to  transmit  data  from  the  WANG 
disk  to  the  NCSS  disk.  As  the  program  is  currently  written,  the  occurrence  of 
"noise"  in  the  telecommunications  link  is  sufficient  to  disrupt  data  transmission. 
This  means  that  the  DBM  must  determine  the  last  data  record  successfully  trans- 
mitted and  restart  the  transmission  process.  Since  telephone  line  "noise"  is 
least  likely  to  occur  after  normal  working  hours,  the  problem  was  temporarily 
solved  by  transmitting  data  from  WANG  to  NCSS  after  5 P.M.  This  problem  was 
discussed  with  the  WANG  district  systems  analyst,  who  has  provided  a skeleton 
program,  which  coupled  with  the  installation  of  a new  Telecommunication  Inter- 
face board  has  alleviated  the  problem. 

SUMMARY  OF  MAINTENANCE  PROCESSING  COSTS.  The  six-month  DOTS  data  base  update 
performed  in  conjunction  with  the  TRAPAC  training  program  not  only  provided  the 
means  to  gain  extensive  hands-on  processing  experience  for  activity  personnel 
and  the  DBM  but  also  provided  sufficient  data  to  project  weekly  maintenance 
costs.  A summary  of  the  data  base  maintenance  activity  and  costs  is  presented 
in  Table  V-1 . 

The  first  column  in  Table  V-1  shows  the  name  assigned  to  the  transaction  file 
on  the  NCSS  disk.  The  date  is  the  date  the  file  was  transmitted  to  NCSS.  Each 
file  may  contain  one  or  several  WANG  tape  cassettes.  The  second  column  shows 
the  total  number  of  maintenance  transactions  recorded  on  the  WANG  tapes.  In- 
cluded in  the  total  of  12,887  transactions  are  7,772  instructor  type  3 trans- 
actions. The  major  use  of  type  3 transactions  was  to  input  instructor  activity 
profile  data.  Since  the  activity  profile  data  is  new  data  and  will  not  be 
entered  in  total  on  a periodic  basis,  it  will  be  excluded  from  the  maintenance 
activity  projection.  However,  profile  data  will  have  to  be  added  for  new  in- 
structors. Assuming  that  150  new  instructors  will  report  during  a six-month 
period,  and  also  assuming  an  average  of  10  profile  records  per  instructor, 
means  that  1,500  of  the  7,772  instructor  records  could  be  considered  to  be 
recurring.  Therefore,  of  the  12,887  total  transactions  6,272  records  were 
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required  to  input  new  data  for  instructors  already  in  the  file  and  are  conse- 
quently non-recurring  inputs.  The  total  number  of  recurring  maintenance  trans- 
actions for  a six-month  time  period  was  6,615,  or  255  transactions  per  week. 

A total  of  11,683  deletions,  additions,  or  changes  were  made  to  the  RAMIS  files. 
A total  of  684  records  were  deleted  from  the  input  files  prior  to  RAMIS  proces- 
sing using  the  CSS  Edit  command.  Some  number  of  records  were  also  modified 
prior  to  RAMIS  processing  using  the  Edit  command.  Edit  costs  are  included  in 
the  NCSS  cost  column.  A total  of  520  records  (12,887  -(11,683  + 684))  were 
rejected  by  RAMIS  and  were  not  entered.  An  additional  number  of  records  were 
also  rejected  by  RAMIS  but  were  analyzed,  modified  and  reentered  as  part  of  the 
training  program.  Although  the  number  of  rejected  transactions  which  were  re- 
entered was  not  recorded,  the  number  is  estimated  to  be  near  500.  All  costs 
associated  with  analyzing,  modifying,  and  reentering  these  transactions  are 
included  in  the  NCSS  cost  figures. 

From  Table  V-1 , the  NCSS  processing  cost  per  input  transaction  ranged  from 
a low  of  1 1 . 5i  to  a high  of  51.5(t.  This  wide  range  is  due  mainly  to  the  dual 
objective  of  the  exercise.  In  addition  to  updating  the  data  base,  the  mainte- 
nance transaction  processing  also  served  as  a training  vehicle  for  the  DBM. 

This  is  especially  true  for  the  first  file  processed  which  averaged  51.5(t  per 
transaction.  Other  factors  affecting  the  cost  per  transaction  are  the  input 
data  error  rate,  the  mix  of  transaction  types,  and  the  number  of  RAMIS  errors 
which  were  analyzed,  corrected,  and  reentered.  The  processing  cost  per  trans- 
action for  periodic  maintenance  is  projected  to  be  in  the  15(1  to  20(1  range. 

ADDITIONAL  NCSS  COSTS.  In  addition  to  the  processing  costs  shown  above,  two 
other  NCSS  costs  should  be  considered:  (1)  cost  to  generate  data  base  listings, 
and  (2)  permanent  storage  costs. 

The  current  cost  to  generate  a complete  TRAPAC  data  base  listing  is  approxi- 
mately $100.  A technique  to  eliminate  this  cost  is  being  pursued  by  the  WANG 
district  systems  analyst.  This  technique  involves  transmitting  the  sequential 
data  base  file  from  NCSS  to  the  WANG  disk,  and  then  formatting  and  printing  the 
file  on  the  WANG  computer.  If  this  technique  proves  to  be  feasible,  the  cost 
to  generate  data  base  listings  would  decrease  to  approximately  $15. 

Permanent  storage  requirements  for  the  DOTS  data  base  and  the  SCRR  and  TPF 
model  software  is  23  120,000-byte  cylinders.  At  current  rates,  the  daily  cost 
of  23  cylinders  is  approximately  $20.  To  minimize  storage  costs,  permanent 
storage  should  be  brought  on-line  for  not  more  than  one  day  per  week  (if  mainte- 
nance is  to  be  performed  weekly).  This  can  be  accomplished  by  storing  all  NCSS 
files  on  magmetic  tape.  The  cost  to  load  all  files  from  tape  to  permanent  disk 
is  approximately  $15.  The  cost  to  write  the  disk  files  back  to  tape  is  also  $15. 
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PROJECTED  MAINTENANCE  COSTS 


RATE 

AVG.  COST/WK 
(255  TRANS/WK) 

WORST  CASE 

AVG.  COST/WK 
(510  TRANS/WK) 

COLLECT  DATA* 

75/HR 

3.4  HR 

6.8  HR 

100/HR 

2.6  HR 

5.1  HR 

ENTER  DATA* 

125/HR 

2.0  HR 

4.0  HR 

200/HR 

1.3  HR 

2.6  HR 

NCSS  PROCESSING  COST 

15(t/TRANS 

$38.25 

$ 76.50 

20(t/TRANS 

$51. 

$102. 

DATA  BASE  LISTING** 

$ 15/WK 

$ 15. 

$ 15. 

$100/WK 

$100. 

$100. 

NCSS  DISK  STORAGE*** 

$ 50/WK 

$ 50 

$ 50. 

TOTALS 

MINIMUM 

3.9  HR  + $103 

7.8  HR  + $142 

MAXIMUM 

5.4  HR  + $201 

10.8  HR  + $252 

* TRAPAC  Total 

**  One  complete  TRAPAC  listing  per  week  |l 


23  Cyl . one  day/week,  loaded  from  tape  and  saved  back  on  tape 
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SYSTEM  DOCUMENTATION 

Documentation,  consisting  of  a combined  user's  guide  and  programmer's  manual  for 
the  DOTS  data  base,  the  SCRR  and  TPF  models,  was  published  in  September  1976  as 
TAEG  Report  No.  36  - Design  of  Training  Systems,  TRAPAC  User's  Manual. 
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